Sự cân bằng tốt giữa các trường tái sử dụng so với việc tạo trường mới trong bối cảnh khả năng mở rộng của trường là gì?

Tôi đã đọc cụm từ sau trên một trang web:

Thay vì thêm các trường mới vào một loại nội dung, thêm các trường hiện có là một lựa chọn tốt hơn để giảm độ phức tạp của hệ thống và để cải thiện khả năng mở rộng.

Và một số nghi ngờ phát sinh.

Trong hệ thống chúng tôi đang phát triển, chúng tôi có khả năng sử dụng lại một trường trên 3 hoặc 4 loại nội dung nhưng thay vì cải thiện khả năng mở rộng như cụm từ được trích dẫn, tôi e rằng nó sẽ làm giảm nó, bởi vì bảng của trường sẽ nhanh hơn trở thành nút cổ chai (ít nhất đó là lý do của tôi trong trường hợp này, vì tất cả các giá trị của lĩnh vực đó cùng nhau, sẽ là một vài triệu mỗi năm và điều đó sẽ làm cho bảng quá lớn). Bạn có đồng ý không?

Có bao nhiêu hàng sẽ là mức tối đa hợp lý để nhắm đến khi kiến ​​trúc? Bằng cách đó, chúng tôi có thể quyết định khi nào sử dụng lại các trường và khi nào tạo trường mới (mặc dù cơ hội để sử dụng lại là có).

Lượng dữ liệu trong một lĩnh vực thường không phải là vấn đề. Nếu bạn lo lắng về điều đó, hãy xem xét các plugin lưu trữ trường thay thế hoặc tự viết. Ví dụ MongoDB , có thể xử lý hầu hết mọi thứ bạn đặt vào nó. Nó là ví dụ được sử dụng trên http://examiner.com .

Một thực tuy nhiên vấn đề là số lĩnh vực mà bạn có. Bởi vì hiện tại trong Drupal 7, cấu hình trường hoàn chỉnh của tất cả các trường, bất kể chúng có được tải hay không, được lấy từ bộ đệm trong mỗi yêu cầu.

Tôi đã thấy các trang web có hơn 250 trường, trong đó việc tải và hủy xác định cấu hình trường chiếm 13 MB + bộ nhớ.

Chỉnh sửa: Bộ đệm thông tin trường đã được cải thiện (xem http://drupal.org/node/1040790 để biết chi tiết) với Drupal 7.22, chỉ các trường gói được hiển thị trên một trang nhất định được tải từ bộ đệm và chúng các mục bộ nhớ cache riêng biệt. Điều đó chỉ hoạt động nếu không có lệnh gọi API sai yêu cầu phiên bản trên nhiều gói.

Tôi hoàn toàn đồng ý với berdir. Dưới đây là kinh nghiệm của tôi với một dự án có hàng triệu hàng và 30-40 trường trên một số loại nút.

1. Số lượng hàng trong bảng trường không phải là vấn đề lớn đối với hiệu suất đọc, vì tất cả các trường được tìm nạp bằng khóa chính.
2. Số lượng các trường trên mỗi loại nút có thể nhanh chóng phát triển thành các vấn đề hiệu suất lớn khi viết các nút mới. Có hơn 30 lĩnh vực cho một nút loại kết quả vào 60 câu lệnh INSERT khi bạn tạo ra một nút mới. Điều này mất vài giây để hoàn thành. Nếu bạn là người dùng tạo nhiều dữ liệu, điều này sẽ ảnh hưởng đến hiệu suất của bạn. Chèn hàng loạt 1000 nút sẽ mất gần một giờ. Nếu bạn phải cập nhật 100.000 nút, đây là một vấn đề lớn.
3. Nếu bạn nghĩ rằng vấn đề về số lượng các lĩnh vực sẽ ảnh hưởng đến bạn, bạn nên nghiêm túc suy nghĩ về việc viết bộ lưu trữ trường của riêng bạn hoặc chỉ không sử dụng các trường. (Bạn vẫn có thể làm cho nút của mình hoạt động với các chế độ xem với một số nỗ lực bổ sung.)
4. Một từ về MongoDB. Đây là một dự án rất thú vị và tôi hy vọng nó sẽ biến nó thành olymp của các DB lớn. Thật không may so với sự trưởng thành của MySql hoặc PGSql đó là một đứa trẻ. Hãy chuẩn bị để đối phó với một sản phẩm rất trẻ.

Nếu bạn thực sự lo lắng về những gì sẽ xảy ra, thì tôi nghĩ rằng một mô phỏng là theo thứ tự.

Nhận một tài khoản tại Rackspace Cloud, Amazon, Linode hoặc bất cứ nơi nào khác mà bạn có thể dễ dàng tạo ra một VPS. Làm hai trường hợp giống nhau. Cài đặt Drupal trên mỗi. Tạo một số loại nội dung giả và thiết lập các trường một cách trong một hệ thống và một cách khác trong hệ thống khác. Sử dụng mô-đun phát để tạo ra một khối lượng nội dung. Điều chỉnh cài đặt hiệu suất để đảm bảo Drupal đang lưu vào bộ nhớ cache khi cần. Chạy mysqltuner và điều chỉnh MySQL trên mỗi lần giới thiệu. Kiểm tra kỹ các cài đặt PHP và APC để bạn không bị trao đổi và bạn không truy cập bộ đệm APC.

Khi bạn nhận được một cấu hình cơ bản tốt cho từng loại, hãy bắt đầu mô phỏng lưu lượng truy cập (cả khách truy cập thông thường và cập nhật quản trị viên) với wget và drush, sau đó cấu hình.

Mô phỏng không bao giờ hoàn hảo, nhưng chúng có thể giúp bạn đi đúng hướng.

Một vấn đề với khả năng mở rộng trong các trường trong việc sử dụng chỉ mục trên mỗi trường bảng duy nhất trong mỗi trường trong bảng được tạo. Chỉ mục cụm khóa chính là tổng hợp của hầu hết các trường, sau đó nó tạo các chỉ mục riêng biệt trên từng trường riêng lẻ. Các chỉ mục tạo ra một tấn ghi trên đầu cho cơ sở dữ liệu và trong hầu hết các trường hợp không bao giờ được sử dụng.

một mẹo khác: có nhiều trường cũng sẽ gây ra vấn đề với nhiều mô-đun khác nhau. Ví dụ, GUI Token sẽ khiến trình duyệt của bạn bị lag trong vài phút nếu bạn cố gắng chỉnh sửa các bí danh url chẳng hạn. Hành vi này có thể được nhìn thấy trên tất cả các trang nơi mã thông báo sẽ được tải và hiển thị (bao gồm cả devel - dpm (), v.v.)

Không có lợi ích hiệu suất trong việc chia dữ liệu này trên nhiều bảng khi sử dụng InnoDB (MyISAM khác vì khóa bảng). Vì vậy - nếu bạn biết bạn sẽ có rất nhiều loại nội dung tương tự với các trường tương tự (cấu hình nào cũng giống nhau, có thể chỉ khác nhau về ghi nhãn) sử dụng lại các trường của bạn!

Nó cũng có thể dễ dàng tạo mẫu vì các thuộc tính nút tương tự.

Chỉ cần chia sẻ câu chuyện của tôi, chúng tôi đang sử dụng Drupal Commerce và có khoảng 40 trường trong các biến thể sản phẩm của chúng tôi (Sku) và sau đó là 460 (vâng, điên rồ) trong Màn hình sản phẩm của chúng tôi. Chúng tôi đã có một số quan điểm so sánh sản phẩm sẽ xem xét tất cả các lĩnh vực này. Không có bộ nhớ đệm, một số tải trang có thể mất đến một phút!

Tuy nhiên, nó đã làm việc. Nếu bạn đã sử dụng bộ nhớ đệm và Varnish, thời gian chờ đợi của người dùng sẽ không tệ.

Vấn đề chính mà chúng tôi gặp phải với rất nhiều lĩnh vực là với Display Suite, vì điều đó sẽ trở nên rất chậm (đôi khi không phản hồi) nếu chúng tôi cố gắng sắp xếp lại hoặc di chuyển một trường xung quanh.

May mắn thay, chúng tôi đã quyết định tính lại các sản phẩm của mình một chút để chúng tôi hy vọng có thể đưa số lượng trường tối đa của mình xuống trong phạm vi 200-250 cho các sản phẩm phức tạp nhất của chúng tôi (chúng tôi đang sử dụng các thiết bị khoa học, vì vậy cần có các phép đo và thông số kỹ thuật phức tạp) .

Đó là một câu hỏi thú vị. Tôi đã từng nghĩ về điều này trước đây, đôi khi việc sử dụng lại một trường có thể thuận tiện để không có vô số trường tương tự 'nằm xung quanh' nhưng có vẻ ngớ ngẩn khi có một loại nội dung nhất định phải chọn từ một tải dữ liệu lớn mà chúng ta biết không có nghĩa là được trả lại trong kết quả.

Tôi cần thêm một chút thông tin về dự án để tư vấn về cách thực hành tốt nhất để nhân rộng. Lưu lượng truy cập dự kiến ​​là bao nhiêu, có bao nhiêu người dùng đăng nhập, v.v. Chẳng hạn, nếu tất cả lưu lượng truy cập ngoại trừ của người dùng quản trị viên của bạn không được xác thực và được lưu trữ ẩn danh

Cho đến nay tôi vẫn luôn sử dụng lại các trường nhưng hiện đang xem xét sử dụng các trường duy nhất cho mỗi loại nút cho một dự án mới. Tôi thực sự muốn giữ mọi thứ tách biệt độc đáo (các trường, khung nhìn, quy tắc, bối cảnh, v.v.) cho mỗi gói thực thể. Vì vậy, nó đặt ra câu hỏi về khả năng mở rộng dẫn tôi đến đây. Tôi được an ủi bởi chỉnh sửa của Berdir (Bộ đệm thông tin trường đã được cải thiện (xem http://drupal.org/node/1040790 để biết chi tiết) với Drupal 7.22, chỉ các trường gói được hiển thị trên một trang nhất định mới được tải từ bộ đệm và chúng là các mục bộ đệm riêng biệt. Điều đó chỉ hoạt động nếu không có lệnh gọi API sai yêu cầu phiên bản trên nhiều gói).

Tôi chỉ muốn chỉ ra rằng có một mô-đun rất thú vị mà tôi đã sử dụng trong nhiều tháng trên nhiều trang web phức tạp.: Https://www.drupal.org/project/render_cache . Theo ý kiến ​​của tôi, đó là một trong những viên ngọc tiềm ẩn.

Như đã nói trên trang dự án, phần bình luận thực sự đang được sử dụng trên chính DO.

Vì vậy, với tất cả những gì trong tâm trí, nó sẽ biến sự đồng thuận có lợi cho các lĩnh vực riêng biệt? Mặc dù vậy, sự cảnh báo được đề cập về DS vẫn còn là một người ồn ào. Thật khó chịu khi cách nó tiết kiệm thông qua ajax thay vì cách giao diện quản trị khối lõi xử lý việc đặt hàng lại. Tôi cảm thấy đó là một vấn đề về DS, mặc dù ...

Theo đề xuất của tôi Sử dụng cùng các trường trong loại nội dung riêng biệt là ý tưởng tốt. Bởi vì nó sẽ cải thiện hiệu suất trang web của bạn. Trong Drupal 7, Khi bạn đang sử dụng thao tác chọn vào thời điểm đó, Sử dụng cùng các trường trong loại nội dung thực sự hữu ích cho trang web Drupal7 của bạn.