Làm thế nào để lưu trữ 3 triệu bản ghi ở định dạng giá trị chính?

10

Chúng tôi phải lưu trữ thông tin cơ bản về 3 triệu sản phẩm. Hiện tại thông tin là một CSV 180 mb được cập nhật hàng quý.

Sẽ có khoảng 30.000 truy vấn mỗi ngày, nhưng các truy vấn chỉ là một kho lưu trữ giá trị khóa rất đơn giản. Chúng tôi chỉ cần tra cứu ID sản phẩm và hiển thị phần còn lại của thông tin (tất cả sẽ nằm trong một bản ghi).

Điều này là dành cho web, vì vậy hiệu suất nhanh là rất quan trọng.

Chúng ta có nên sử dụng MySQL, mặc dù chúng ta thực sự không cần một cơ sở dữ liệu quan hệ? Chúng ta có nên tạo 3 triệu tệp html tĩnh mỗi quý không? Chúng ta có nên lưu trữ một dòng CSV cho mỗi sản phẩm trên một cái gì đó như Amazon S3 hoặc Rackspace Cloud Files không? Cách tốt nhất để làm việc này là gì?

— Phil
nguồn

16

Bởi vì MySQL được hỗ trợ rất rộng rãi và đây thực sự là một việc khá tầm thường nên tôi khuyên bạn nên đi với nó. Trừ khi máy chủ có ít nhất vài GB bộ nhớ, tôi sẽ đề nghị gắn bó với MySQL hơn là sử dụng hệ thống trong bộ nhớ.

Khi bạn bắt đầu đưa dữ liệu của mình vào cơ sở dữ liệu, cho dù đó là MySQL hay thứ gì khác, bạn hoàn toàn có thể thấy rằng bạn sẽ tìm thấy nhiều cách sử dụng hơn cho nó. Ngay bây giờ bạn chỉ nói về các cặp giá trị chính nhưng phần còn lại của dữ liệu liên quan đến sản phẩm của bạn phải được lưu trữ ở đâu đó. Nếu không có trong cơ sở dữ liệu, tôi không thể tưởng tượng việc lưu trữ dữ liệu rất hiệu quả.

Dù bạn làm gì, đừng tạo ba triệu tệp đó. Chúng tôi đã thấy một số câu hỏi ở đây đã xuất phát từ các vấn đề rất nhiều tệp tạo ra.

— John Gardeniers
nguồn

13

Bạn có thể sử dụng loại cơ sở dữ liệu No-Key chuyên dụng của cơ sở dữ liệu NoQuery được tối ưu hóa cho loại tác vụ này. Có một cái nhìn tại:

Redis - Redis là một kho lưu trữ khóa-giá trị nâng cao. Nó thường được gọi là một máy chủ cấu trúc dữ liệu vì các khóa có thể chứa chuỗi, băm, danh sách, bộ và bộ được sắp xếp.
MemcacheDB - MemcacheDB là một hệ thống lưu trữ khóa-giá trị phân tán được thiết kế cho liên tục.
những người khác (một trong những danh sách như vậy có thể được tìm thấy ở đây: http://nosql-database.org/ )

Tất nhiên bạn có thể sử dụng MySQL hoặc bất kỳ cơ sở dữ liệu quan hệ nào khác, nhưng các giải pháp được thiết kế đặc biệt cho loại dữ liệu khóa-giá trị được cho là tốt hơn (nếu không thì điểm nào là thiết kế chúng ở vị trí đầu tiên, ngoại trừ có thể thực tế là nó sẽ nhỏ hơn nhiều (về mặt giải pháp RAM và HDD).

— LazyOne
nguồn

Chúng tôi có thể sử dụng Redis, nhưng bạn có nghĩ rằng nó sẽ hoạt động trên P4 với 2 hợp đồng RAM?

— Phil

@Phil Xem xét tệp CSV của bạn khoảng 180 MB - sẽ ổn thôi. Mặc dù chúng tôi đã sử dụng nó trong một dự án (chỉ một lần cho đến nay) với khoảng 200 nghìn bản ghi và máy chủ có RAM 8GB nên tôi rất khó so sánh.

— LazyOne

6

Và bây giờ cho một cái gì đó hoàn toàn khác nhau:

Được:

Trung bình 180MB / sản phẩm 3M = 62 byte / sản phẩm.
30.000 truy vấn mỗi ngày = 0,34 truy vấn mỗi giây
Cập nhật hàng quý = dữ liệu tĩnh

Giải pháp bên ngoài hộp:

Kết xuất mỗi sản phẩm dưới dạng bản ghi tài nguyên TXT và lưu trữ nó trong DNS, ví dụ:

$origin products.example.com.

product_1_name IN TXT "product 1 description"
product_2_name IN TXT "product 2 description"
...
product_3000000_name IN TXT "product 3000000 description"

Những lợi ích:

cực kỳ đáng tin cậy và đáng tin cậy (bạn đã phụ thuộc vào nó mỗi ngày)
có thể được xây dựng trên hầu hết mọi nền tảng
hầu như mọi ngôn ngữ đều hỗ trợ các truy vấn DNS ở dạng này hay dạng khác
mã nguồn mở và máy chủ thương mại hỗ trợ các loại cơ sở dữ liệu phụ trợ khác nhau
có thể được sao chép một cách tầm thường (chỉ cần chỉ định nhiều máy chủ tên)
xử lý các cập nhật nguyên tử, ngay cả khi được nhân rộng trên một tá máy chủ
có thể được ký bằng mật mã để đảm bảo tính toàn vẹn dữ liệu
có thể xử lý các đơn đặt hàng có cường độ truy vấn cao hơn mỗi giây (10.000 truy vấn mỗi giây được xử lý dễ dàng với phần cứng hàng hóa)

Lý do tại sao điều này có thể là một ý tưởng tồi:

bạn cần tìm kiếm dữ liệu (DNS hoàn toàn là tra cứu khóa / giá trị)
bạn cần ẩn dữ liệu (DNS không được bảo mật)

— Theobroma Cacao
nguồn

1

Nếu tôi có thể cho điểm thưởng cho tính nguyên bản, điều này sẽ nhận được phiếu bầu của tôi. Mặc dù vậy, tôi không nói DNS đáng tin cậy, vì trên một mạng gia đình thông thường, nó có vẻ như là phép thuật nếu nó hoạt động và là một lời nguyền nếu không.

— Martin Vilcans

1

Tôi tò mò. Tôi thực sự rất thích ý tưởng này, nhưng đối với tôi, tôi sẽ thử một thứ gì đó đã thử / thử nhiều hơn một chút như CouchDB

— Tom O'Connor

Đang xem một số Monty Python?

— Đánh dấu Henderson

Có lẽ điều này sẽ nằm trong một mạng doanh nghiệp. Độ tin cậy của DNS trở thành một vấn đề khi các gói phải can đảm vào sự hoang dã của Internet. Vì theo mặc định, DNS sử dụng UDP, bạn phải dựa vào chính sách truyền lại của trình phân giải DNS nếu gói bị bỏ. Trong mạng doanh nghiệp, khả năng bạn bị mất gói đáng kể là rất đáng kể. Và bạn luôn có thể buộc DNS sử dụng TCP (mặc dù có hiệu suất cao, được cho là không đáng kể trong trường hợp này). Và tôi đảm bảo, DNS nhận được nhiều tra cứu hơn tất cả các cài đặt CouchDB được kết hợp :-).

— Theobroma Cacao

Thuyền trưởng Hindsight đây. Một từ: blockchain.

— datashaman

4

MySQL với MyISAM và một số chỉ mục tốt nghe có vẻ hoàn hảo cho việc này. Tất nhiên có rất nhiều tùy chọn khác, nhưng MySQL rất rộng rãi (nếu không phải là phổ biến) được hỗ trợ trên bất kỳ máy chủ web thương mại nào. Tùy thuộc vào tốc độ bạn yêu cầu, memcached cũng có thể đáng xem , nhưng không biết kích thước của từng cặp khóa / giá trị, lưu trữ 3 triệu trong số chúng trong bộ nhớ có thể là ý tưởng thậm chí còn tồi tệ hơn tệp CSV 180Mb (chờ đã, đó là một tệp CSV 180Mb, vì vậy chúng tôi biết chúng lớn như thế nào. Chúng phải là những cặp nhỏ xinh, vì vậy memcached có thể còn tốt hơn nữa).

Bạn không muốn 3 triệu tệp HTML tĩnh, điều đó sẽ làm tổn hại đến hệ thống tệp của bạn. Một CSV một dòng, ngay cả trên S3, cũng sẽ gặp vấn đề tương tự. Không ai muốn 3 triệu tệp trong một thư mục.

— Mark Henderson
nguồn

Chúng là những cặp khá nhỏ ... đó là dữ liệu rất cơ bản như giá cả, ngày sản xuất, số lượng kho, v.v ... Dưới 10 cột. Vì vậy, bạn nghĩ rằng MySQL là con đường để đi, thực sự? Máy chủ sắp chạy là P4 với 2 hợp đồng RAM - Tôi nghĩ điều đó có ổn không?

— Phil

@Phil - So you think MySQL is the way to go, really?- không, không thực sự, nhưng nó rất linh hoạt và như tôi đã đề cập, được hỗ trợ gần như toàn cầu. Tuy nhiên LazyOne đã đăng một số lựa chọn thay thế tốt ở trên. Tôi không thể nhớ thuật ngữ NoQuery, nhưng nó xuất hiện trong não tôi ở đâu đó

— Mark Henderson

4

Bạn có thể sử dụng Cơ sở dữ liệu Berkeley thực hiện chính xác loại điều này, ngay cả khi nó không hoạt động kể từ buổi bình minh của Perl5. Berkeley chỉ hỗ trợ các cặp giá trị khóa và bạn buộc toàn bộ db vào hàm băm và truy cập nó như vậy.

Sử dụng Berkeley rất chi tiết trong nhiều tài liệu tham khảo Perl cũ hơn trên kệ của bạn hoặc thử Perldoc cho Mô-đun CPAN BerkeleyDB . Tôi thường tránh sử dụng Berkeley DB (mặc dù chủ nhân của tôi có nhiều mã cổ xưa, trong đó nó chơi nổi bật và một số DB lớn như của bạn), vì không có gì thú vị khi dữ liệu của bạn phức tạp hơn.

— Brainbuz
nguồn

2

BDB là skool cũ nhưng rất hiệu quả và phù hợp với tình huống này.

— womble

Cảnh giác với giấy phép cho Berkely DB en.wikipedia.org/wiki/S ngủycat_license, nó yêu cầu TẤT CẢ mã nguồn được cung cấp không chỉ là phần DB.

— WolfmanJM

4

Bạn đã gắn cờ câu hỏi của bạn là amazon S3.

Tôi muốn thu hút sự chú ý của bạn đến một trong những sản phẩm liên quan khác của họ được gọi là Amazon SimpleDB.
Có vẻ như mô hình dữ liệu SimpleDB sẽ phù hợp với loại ứng dụng của bạn.

Đây không phải là một đầu cắm cho nó, nhưng đáng để xem xét đặc biệt là nếu bạn dự định sử dụng các dịch vụ đám mây của Amazon.

Mô hình dữ liệu SDB giống như một bảng tính.

Xem tại đây để biết thêm thông tin về nó: http://aws.amazon.com/simplingb/ Và mô hình dữ liệu: http://docs.amazonwebservice.com/AmazonSimpleDB/latest/DeveloperGuide/

— Matt
nguồn

SimpleDB là đắt tiền. Đau đớn như vậy, trong nhiều trường hợp.

— Tom O'Connor

1

Mặc dù 180mb dữ liệu có thể được xử lý dễ dàng bởi bất kỳ cơ sở dữ liệu quan hệ nào, tôi rất khuyến nghị MongoDB ( http://www.mongodb.org/) ở trên MySQL, Redis, MemcacheDB và các kho lưu trữ khóa-giá trị đơn giản khác hoặc cơ sở dữ liệu quan hệ. Lý do là vì loại vấn đề này, MongoDB là hệ thống nhanh nhất, biểu cảm nhất để sử dụng, cho phép cập nhật động cực nhanh mà không bị hạn chế lược đồ, vì vậy tài liệu của bạn có thể có các định dạng khác nhau nếu bạn muốn. Tôi đã có mặt tại một buổi thuyết trình từ Guardian.co.uk vào một ngày khác và họ đã đưa ra quyết định chính sách cấm tất cả các cơ sở dữ liệu quan hệ và sử dụng MongoDB một cách toàn diện để phục vụ tin tức của họ. Bạn có thể cảm nhận được trang web của họ nhanh như thế nào và đã trực tuyến từ năm 1995 (tờ báo trực tuyến lâu đời nhất ở Anh). Họ cũng đã trải qua tất cả các loại tắc nghẽn trong quá khứ vì cơ sở dữ liệu quan hệ. Với 180mb, MongoDB sẽ phục vụ mọi thứ từ trong bộ nhớ, vì vậy thời gian tải phụ ms có thể là trường hợp.

— snez
nguồn

0

Sẽ có khoảng 30.000 truy vấn mỗi ngày, nhưng các truy vấn chỉ là một kho lưu trữ giá trị khóa rất đơn giản. Chúng tôi chỉ cần tra cứu ID sản phẩm và hiển thị phần còn lại của thông tin (tất cả sẽ nằm trong một bản ghi).

Bạn nói rằng các truy vấn của bạn chỉ là các tra cứu khóa đơn giản, với tìm kiếm nhị phân, bạn cần 21 lần lặp trong trường hợp xấu nhất, với các khóa băm, các truy vấn của bạn thậm chí còn nhanh hơn. Ba triệu bản ghi là nhỏ miễn là bạn tránh tham gia (hoặc các hoạt động loại sản phẩm cartesian khác) và tìm kiếm tuyến tính.

Tôi dám nói gần như mọi thứ sẽ làm tốt. Tải của bạn là 30000 truy vấn / ngày có nghĩa là (giả sử tải của bạn không đổi trong cả ngày), bạn có một truy vấn duy nhất cứ sau 20 giây; Điều đó không quá tệ.

Tôi khuyên bạn nên triển khai công nghệ mà bạn quen thuộc nhất trước tiên và sau đó đo xem đây có thực sự là nút cổ chai của hệ thống hay không.

— Nói dối Ryan
nguồn

0

Cách tốt nhất để làm điều này thực sự phụ thuộc vào chất lượng và bản chất của dữ liệu và truy vấn của bạn. Đối với người mới bắt đầu, 180 MB dữ liệu trong một bảng cho các sản phẩm không phải là vấn đề, bất kể bạn nhìn nó như thế nào. Và 30k truy vấn mỗi ngày thậm chí còn ít vấn đề hơn. Với một cơ sở dữ liệu được cấu hình đúng, bất kỳ máy tính để bàn cũ nào cũng có thể xử lý tải này.

Những người khác đã chỉ ra hai tùy chọn chính của bạn, MySQL hoặc cơ sở dữ liệu noQuery.

Nếu bạn có một số thuộc tính nhất định tồn tại cho mỗi sản phẩm (như nhà sản xuất, giá, số kho, v.v. thì tùy chọn tốt nhất của bạn là có các cột cho các thuộc tính này và chuyển đổi các cặp khóa / giá trị của bạn thành định dạng bảng phẳng, với ID sản phẩm là khóa chính cho bảng đó. Điều này sẽ hoạt động rất tốt ngay cả khi một số cột chỉ được sử dụng bởi một nửa số hàng, vì đối với hầu hết các sản phẩm, bạn sẽ chỉ cần chạy 1 truy vấn để truy xuất tất cả các thuộc tính của chúng. Đây là dữ liệu về sản phẩm, tôi đoán rằng có khả năng đây là cấu trúc dữ liệu của bạn.

Nếu các thuộc tính khác nhau về sự hiện diện và loại dữ liệu, thì bạn có thể sử dụng cơ sở dữ liệu noQuery tốt hơn, xử lý tình huống này hiệu quả hơn so với cơ sở dữ liệu SQL truyền thống.

Về hiệu suất: Trước đây tôi đã từng làm việc cho một công ty thương mại điện tử, trong một thời gian dài trang web được cung cấp dữ liệu từ máy chủ MySQL. Máy chủ này có 2GB RAM, tổng số cơ sở dữ liệu là xấp xỉ. Kích thước 5GB và tải dưới cùng, máy chủ xử lý vài nghìn truy vấn mỗi giây. Vâng, chúng tôi đã thực hiện rất nhiều tối ưu hóa truy vấn, nhưng điều này chắc chắn là có thể thực hiện được.

— sóigangsz
nguồn