2)Về mấy cái ngôn ngữ lập trình thì cái ra đời sau thường hay hơn cái trước.Bây giờ sau C đã có D,sau Java đã có Ruby...Ko biết mai mốt rồi sẽ ra cái gì nữa đây...!
Ruby, đặc biệt là Ruby On Rail, gây bất ngờ lớn cho phần dev web application nhỉ. Mình cũng rất thú vị xem thử sự phát triển của nó như thế nào...
Có project All-In-One, build eclipse+plugin rất tiện. Nếu anh em nào sử dụng eclipse nên dùng thử thành quả của project này. http://sourceforge.jp/projects/aioec/
Thông tin về servers của Livedoor được công bố như sau:
OS: FreeBSD/Linux(với tỷ lệ: 7/3) (Không dùng Win, FreeBSD lại chiếm tỷ lệ lớn nhất, thật bất ngờ) Web Server: Apache 1x & 2x DB Server: MySQL4.0 Dev Language: Perl(mod_perl1) Tổng số servers: 3000 (thuộc IA(Intel Arch) server)
※ Một số thông tin khác: 1. Ứng với một project bất kỳ, cấu trúc tối thiểu của livedoor như sau: Director: 1nguoi, Programer, Designer, HTML Templeter: tối thiểu 1 người 1 vị trí.
2. Lý do tại sao sử dụng mod_perl Sử dụng mod_perl vì - tính performance - trình độ và kinh nghiệm có sẵn trong livedoor - tính ổn định (không sử dụng mod_perl2 cũng vì lý do này) -> Và điều này cũng có thể giải thích luôn cho lý do tại sao sử dụng Mysql4.0 - Perl/CPAN lib phong phú.
3. Một số application arch points: - Sử dụng mod_rewrite, mod_proxy để balance application server và static contents delivery server. - Sử dụng DB replication. 1 master + trên 1 slave servers - Những dữ liệu DB chủ yếu xem, không có action update thường xuyên sử dụng type MyISAM, và ngược lại sử dụng InnoDB - Sử dụng memcached để lưu các static contents trên memory - Sử dụng mod_deflate để nén đường truyền - Dùng mod_expire để kéo dài cache trên browser client - Sử dụng kiểu 2-layer server: Clien <-> Application Server(Contents Server+Mod_perl App Serrver) <-> DB server
Theo anh biết chỉ cần biết những loại sau là đủ. + Tầng TCP: TCP(SOCK_STREAM) or UDP(SOCK_DGRAM) + Tầng IP: PF_UNIX, PF_LOCAL(local sock) PF_INET(IPv4) PF_INET6(IPv6)
Vấn đề RedHat không tham gia LinuxWorld năm nay gây nhiều tranh cãi lắm. Ai cũng đoán già đoán non tuy nhiên phía Redhat chưa hề cho biết lý do tại sao cả. Không biết có chiến lược ý đồ gì không
1. Nhìn lại lịch sử một chút chúng ta có thể thấy rõ ràng rằng: Từ application sử dụng flat data để store thông tin -> Chuyển sang sử dụng Database server.
Bước chuyển này rất là ngoạn mục lắm, hầu như performance application được nâng cấp, dữ liệu data có lớn cũng không còn là vấn đề đáng ngại nữa... Các kỹ thuật để thiết lập cấu trúc cho DB đã được khai thác và phát triển liên tục đến giờ có thể nói là đã hoàn chỉnh lắm.
Tuy nhiên vấn đề có vẻ không chỉ dừng lại, bản thân DB cũng nằm trên Harddisk, và mỗi lần muốn có dữ liệu phải dùng SQL để lấy, điều này đến lúc sẽ đạt đến sự giới hạn của nó mà không thể thoã mãn được thời đại sau này.
Chính vì vậy mà: Từ application sử dụng flat data để store thông tin -> Chuyển sang sử dụng Database server -> Tất cả cho vào memory
Tức là khi application khởi động tất cả dữ liệu sẽ được cho tất vào memory, điều đó sẽ: + Tốc độ access cực nhanh + Có thể không phải qua trung gian tái tạo, kết hợp để tạo dữ liệu cuối cùng. Ví dụ: Thường thì một class Student, có tên, tuổi, môn học, lớp trường, trước đến giờ học ở đâu, thành tích thế nào, con ai ông bà nào, quê quán ở đâu... Để lấy thông tin của object Student này, thường phải SQL hằng loạt tables trong DB, sau đó tái tạo, kết hợp, khi cần phải chạy một số logic khác nhau mới có thể cho ra Object Student được... Tuy nhiên cả cái Object này nếu được nằm luôn trên memory thì lần sau chỉ cần get data trên memory là xong. Điều này sẽ nhanh không thể tưởng tượng được...
Thời đại bây giờ, khi các hardware dùng cho máy tính ngày càng rẽ, dung lượng memory không khác gì Hardware cả thì việc nói ở trên đã không còn là điều khó thực hiện.
2. Về kỹ thuật cho phần này thì bây giờ đã như thế nào nhỉ? Theo như hiểu biết của mình thì như sau: + Các application có riêng architecture riêng để store data trên memory... Các ngôn ngữ đều có chức năng này, tuy nhiên để làm được điều này cần phải đòi hỏi trình độ của người thiết lập cấu trúc cho chương trình, và tránh sự xung khắc với các application khác của system... + Sử dụng các soft thirdparty về cache data lên memory. Những cái này có nhiều, ví dụ memcached + Thiết lập filesystem tren memory luôn. Ví dụ FreeBSD Memory Filesystem + Các application server như Jboss, WebSphere có riêng chức năng cache của mình
+++ Và quan trọng nhất là gần đây, bản thân các DB software đã được chức năng này vào DB của mình. Ví dụ: Mysql http://opentechpress.jp/article.pl?sid=06/09/04/0227228&from=rss http://tangent.org/index.pl?lastnode_id=478&node_id=506
Phải công nhận nếu như trong bản thân các DB có sẵn chức năng này thì phía application dev sẽ rất là tiện lợi lắm. Vì không còn phải nghĩ ngợi hay viết code để thực hiện động tác này nữa.
