Як зберігати 3 мільйони записів у форматі ключових значень?

Ми повинні зберігати основну інформацію про 3 мільйони продуктів. На даний момент інформація становить один 180 Мб CSV, який оновлюється щоквартально.

Буде близько 30 000 запитів на день, але запити - це просто дуже просте сховище ключових значень. Потрібно лише пошукати ідентифікатор продукту та відображати решту інформації (яка б була в одному записі).

Це для Інтернету, тому швидка продуктивність є критичною.

Чи варто використовувати MySQL, навіть якщо нам насправді не потрібна реляційна база даних? Ми повинні просто генерувати 3 мільйони статичних HTML-файлів щоквартально? Чи варто зберігати однорядковий CSV для кожного продукту на щось на зразок Amazon S3 або Cloud Cloud Files? Який найкращий спосіб зробити це?

Оскільки MySQL настільки широко підтримується, і це дійсно досить тривіальна річ, я б запропонував піти з ним. Якщо сервер не має принаймні декількох ГБ пам'яті, я б запропонував дотримуватися MySQL, а не використовувати систему пам'яті.

Як тільки ви почнете вносити свої дані в базу даних, будь то MySQL чи щось інше, ви, швидше за все, виявите, що знайдете для неї більше використання. Зараз ви говорите лише про пари ключових значень, але решта даних, що стосуються ваших продуктів, повинні зберігатися десь. Якщо цього немає в базі даних, я не можу уявити, що зберігання даних є дуже ефективним.

Що б ви не робили, не створюйте цих трьох мільйонів файлів. Тут ми вже бачили ряд питань, що виникають із-за проблем, що створюються багатьма файлами.

Ви можете використовувати виділений тип «Ключ-Значення» бази даних NoSQL, який оптимізований для подібних завдань. Подивіться на:

• Redis - Redis - це відкритий, просунутий ключ-цінність із відкритим кодом. Його часто називають сервером структури даних, оскільки ключі можуть містити рядки, хеші, списки, набори та сортовані набори.
• MemcacheDB - MemcacheDB - це розподілена система зберігання ключів і значень, розроблена для стійких.
• інші (один із таких списків можна знайти тут: http://nosql-database.org/ )

Звичайно, ви можете використовувати MySQL або будь-яку іншу реляційну базу даних, але рішення, спеціально розроблені для типу ключових значень, повинні вважатись кращими (інакше в чому сенс їх проектувати, за винятком, можливо, того, що він буде набагато меншим (з точки зору оперативної пам’яті та жорсткого диска).

А тепер про щось зовсім інше:

Подано:

• 180MB / 3M продуктів = 62 байти / продукт в середньому.
• 30 000 запитів на день = 0,34 запиту в секунду
• Оновлено щоквартально = фактично статичні дані

Поза рішення коробки:

Скиньте кожен продукт у вигляді запису ресурсів TXT і збережіть його в DNS, наприклад:

$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"

Переваги:

• надзвичайно надійний і надійний (ви вже від цього щодня залежите)
• можна побудувати на майже будь-якій платформі
• майже кожна мова має підтримку DNS-запитів у тій чи іншій формі
• з відкритим кодом та комерційні сервери підтримують різні типи баз даних
• можна тривіально тиражувати (просто вкажіть кілька серверів імен)
• обробляє атомні оновлення, навіть коли вони тиражуються на десяток серверів
• може бути криптографічно підписаний для забезпечення цілісності даних
• може обробляти замовлення на величину вищих запитів за секунду (10 000 запитів в секунду легко обробляються товарним обладнанням)

Причини, чому це може бути поганою ідеєю:

• вам потрібно здійснити пошук даних (пошук DNS - це суто ключ / значення)
• вам потрібно приховати дані (DNS не має конфіденційності)

MySQL з MyISAM та деякими хорошими індексами звучить ідеально для цього. Звичайно, існує багато інших варіантів, але MySQL дуже широко (якщо не універсально) підтримується на будь-якому комерційному веб-хості. Залежно від потрібної вам швидкості складання пам’яті, можливо, варто також переглянути , але, не знаючи розміру кожної пари клавіш / значень, зберігання 3 мільйонів з них у пам'яті може бути ще гіршою ідеєю, ніж CSV-файл у форматі 180 Мб (зачекайте, це файл у форматі CSV на 180 Мб, тож ми знаємо, наскільки вони великі. Вони повинні бути досить маленькими парами, щоб запам'ятоване може бути ще кращим).

Ви не хочете 3 мільйони статичних HTML-файлів, це сильно зашкодить вашій файловій системі. Однорядковий CSV, навіть на S3, матиме таку ж проблему. Ніхто не хоче 3 мільйони файлів у папці.

Ви можете використовувати базу даних Берклі, яка робить саме такі речі, навіть якщо це не було стегна з самого світанку Perl5. Берклі підтримує лише пари ключових значень, і ви прив’язуєте весь db до хешу і отримуєте доступ до нього як такого.

Використання Берклі добре деталізовано у багатьох старих посиланнях Perl, що сидять на вашій полиці або спробуйте Perldoc для модуля CPAN BerkeleyDB . Я, як правило, уникаю використання Berkeley DB (хоча мій роботодавець має дуже давній код, в якому він грає чітко, а деякі БД є такими ж великими, як і ваш), тому що це не весело, коли ваші дані стають складнішими.

Ви позначили своє запитання як amazon S3.

Я хотів би звернути вашу увагу на один із інших пов'язаних з ними продуктів під назвою Amazon SimpleDB.
Здається, що модель даних SimpleDB добре поєднується з вашим типом програми.

Це не плагін для цього, але варто звернути увагу, особливо якщо ви плануєте використовувати хмарні сервіси Amazon.

Модель даних SDB нагадує електронну таблицю.

Дивіться тут для отримання додаткової інформації про нього: http://aws.amazon.com/simpledb/ І модель даних: http://docs.amazonwebservices.com/AmazonSimpleDB/latest/DeveloperGuide/

Незважаючи на те, що 180mb даних можна легко обробляти будь-якою реляційною базою даних, я б дуже рекомендував MongoDB ( http://www.mongodb.org/) над MySQL, Redis, MemcacheDB та іншими простішими сховищами ключових значень або реляційними базами даних. Причина полягає в тому, що для подібних проблем MongoDB - це найшвидша та найвиразніша система, яка дозволяє використовувати надшвидкі динамічні оновлення без обмежень схеми, тому ваші документи можуть мати різні формати, якщо вам це подобається. Днями я був на презентації від Guardian.co.uk, і вони прийняли політичне рішення заборонити всі реляційні бази даних та використовувати MongoDB виключно для подачі своїх новин. Ви можете відчути, наскільки швидко працює їхній веб-сайт і який працює в Інтернеті з 1995 року (найстаріша інтернет-газета Великобританії). Вони також пройшли через всілякі вузькі місця в минулому через реляційні бази даних. Для 180mb, MongoDB буде обслуговувати все з пам'яті, тому час завантаження суб-мс, ймовірно, має місце.

Буде близько 30 000 запитів на день, але запити - це просто дуже просте сховище ключових значень. Потрібно лише пошукати ідентифікатор продукту та відображати решту інформації (яка б була в одному записі).

Ви сказали, що ваші запити - це просто просте пошуку ключів, для двійкового пошуку вам потрібні 21 ітерація в гіршому випадку, а хешовані клавіші ваші запити ще швидші. Три мільйони записів невеликі , якщо ви уникаєте приєднань (або інших декартових операцій типу продукту) та лінійних пошукових запитів.

Сміла б сказати майже все, що було б добре. Ви завантажуєте 30000 запитів на день, це означає, що (якщо ви завантажуєте постійне протягом дня) у вас є один запит кожні 20 секунд; це не дуже погано.

Я рекомендую реалізувати в тій технології, яку ви найперше знайомі, а потім виміряйте, чи справді це вузьке місце системи.

Найкращий спосіб зробити це дійсно залежить від якості та характеру ваших даних та запитів. Для початківців 180 Мб даних в одній таблиці для продуктів не є проблемою, незалежно від того, яким чином ви її дивитесь. І 30-ти запитів на день - це ще менше проблеми. За допомогою правильно налаштованої бази даних будь-який старий робочий стіл може впоратися з цим навантаженням.

Інші вже вказали на два ваші основні параметри - MySQL або базу даних noSQL.

Якщо у вас є певна кількість атрибутів, які існують для кожного окремого товару (наприклад, виробник, ціна, номер складу тощо), то найкращим варіантом є створення стовпців для цих атрибутів і перетворення ваших пар ключів / значень у формат плоскої таблиці, з ідентифікатором продукту в якості основного ключа для цієї таблиці. Це буде дуже добре, навіть якщо деякі стовпці використовуються лише половиною рядків, оскільки для більшості продуктів вам потрібно буде виконати лише 1 запит, щоб отримати всі їх атрибути. Враховуючи, що це дані про продукти, я б здогадався, що цілком ймовірно, що це структура ваших даних.

Якщо атрибути сильно відрізняються за наявністю та типом даних, то вам може бути краще використовувати базу даних noSQL, яка обробляє цей сценарій більш ефективно, ніж традиційні бази даних SQL.

Щодо продуктивності: я раніше працював у компанії з електронної комерції, де тривалий час веб-сайт забезпечувався даними з сервера MySQL. Цей сервер мав 2 ГБ оперативної пам’яті, загальна база даних становила бл. Розміром 5 Гб і під максимальним завантаженням сервер обробляв кілька тисяч запитів в секунду. Так, ми провели багато оптимізації запитів, але це, безумовно, можливо.