5 reasons why the Drupal CMS is not ready for the...

Events happening in the community are now at Drupal community events on www.drupal.org.
dom.killer's picture

http://www.hiveminds.co.uk/node/3740
Many Open Source content management systems written in PHP want to be recognized by the business industry as being "enterprise" ready. This is not only a mark of prestige and status but places them in a position where large companies are ready to invest in the software as a platform for their projects. Drupal is now trying making its move to be enterprise ready but has a long way to go.

Trong bài viết này có chỗ database, tất cả đều chứa trong node table. Tuy chưa nếm trải qua nhưng em cũng hình dung database sẽ nặng và chậm khi site càng lớn dần. Em nghe nói tamtay cũng đang vất vả với nó. Liệu có cách thiết kế nào khác không?

Comments

Bạn đã có công đọc

thehong's picture

Bạn đã có công đọc bài đó rồi thì ráng đọc thêm mấy công thức nấu các site hạng nặng luôn nhé: http://drupal.org/success-stories

--
Thế Hồng

Không phải bài viết

jcisio's picture

Không phải bài viết nào cũng đúng. Bài viết bạn nêu ra là 1 thí dụ điển hình. 1 cái table node quá lớn cũng đâu sao, đã có nhiều site dùng MySQL mà số record trong 1 table lên đến nhiều tỉ (10^9) mà.

Vấn đề chính có lẽ là đọc/ghi thôi. Drupal chưa có cơ chế tách biệt ra, thí dụ hạn chế update 1 table rất lớn như node. Đây là vấn đề chung cho mọi CMS thôi, vì một CMS không phải là một script chuyên biệt (như VBB là 1 forum, nó giải quyết tốt được điều này).

Có thể Drupal không phải là lựa chọn tốt cho 1 vài xí nghiệp, nhưng lại là lựa chọn tốt cho đa số đấy.

--
www.thongtincongnghe.com
Trang tin điện tử về CNTT, Viễn thông, Điện tử...

Data càng lớn thì càng

dom.killer's picture

Data càng lớn thì càng tốn thêm tiền chứ sao lại không sao. Tiền thì có khi $10 cũng như 10 đồng nhưng tốc độ đọc của đĩa cứng vẫn chưa tăng đáng kể, dung lượng RAM, tiền bạc vẫn còn hạn chế... :D

VBB em thấy nó thuộc loại hàng khủng gấp mấy lần Drupal chứ đâu phải vừa.

"Data càng lớn thì càng

jcisio's picture

"Data càng lớn thì càng tốn thêm tiền" - cái này đúng rồi, mà có liên quan gì đến nội dung đang thảo luận ? Hơn nữa, có đúng cũng còn phải xem tốn thêm bao nhiêu, ảnh hưởng gì đến mình không ? Nếu có 1 trang web có 1 triệu bài viết, 100.000 lượt truy cập mỗi ngày thì chi phí để nâng cấp dung lượng từ 100 GB lên 200 GB chẳng đáng là bao so với thu nhập. Mà khi so tốc độ đâu phải 200 GB thì truy cập lâu gấp 2 cái 100 GB đâu.

vBB là hàng khủng ? Ừ đúng rồi. Cũng giống như cây bút bi nó khủng gấp mấy lần cái máy tính ấy chứ ("nhập liệu" nhanh hơn mà). So sánh CMS này với CMS kia đã khó, còn so sánh 2 công cụ có mục đích khác nhau sao so sánh được :(

--
www.thongtincongnghe.com
Trang tin điện tử về CNTT, Viễn thông, Điện tử...

Ý em hàng khủng là

dom.killer's picture

Ý em hàng khủng là nặng nề, khủng hoảng :D Tại anh khơi VBB ra trước đó chứ :D Nhưng thảo luận mãi mà vẫn chưa ra giải pháp hay hơn cách drupal đang làm, hichic

Anh đã thử đọc table 200GB dung lượng chưa ?

Chưa thử, nhưng database

jcisio's picture

Chưa thử, nhưng database 200 GB (20 triệu record ?) cũng đâu lớn lắm đâu. SELECT FROM đơn giản chắc < 0.1 s

--
[vi] www.thongtincongnghe.com
Trang tin điện tử về CNTT, Viễn thông, Điện tử...

Theo em, nếu em có một trang

luatviettin's picture

Theo em, nếu em có một trang đã có dạng GB database hoặc lượt truy cập lên tới mũ 6 mũ 9 thì thừa tiền nâng RAM của thằng server lên tới mức khủng rồi, bật các loại cache lên, chơi được hết.

Thằng tầm tay hiện nay đang chơi dạng cache SQL, nó cache tới 10 phút lận, bằng chứng là đăng bài viết cái phải x phút sau mới lưu và mọi người mới truy xuất được, thử xem !

Co rat nhieu cach de quan ly

phoang's picture

Co rat nhieu cach de quan ly 1 website co so luong users truy cap lon. Mot trong nhung giai phap do la dung load balancing servers va cache.