Как хранить 3 миллиона записей в формате значения ключа?

Мы должны хранить основную информацию о 3 миллионах продуктов. В настоящее время информация представляет собой один CSV 180 МБ, который обновляется ежеквартально.

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

Это для Интернета, поэтому высокая производительность очень важна.

Должны ли мы использовать MySQL, даже если нам действительно не нужна реляционная база данных? Должны ли мы генерировать 3 миллиона статических HTML-файлов каждый квартал? Должны ли мы хранить по одной строке CSV для каждого продукта на чем-то вроде Amazon S3 или Rackspace Cloud Files? Каков наилучший способ сделать это?

Поскольку MySQL так широко поддерживается, и это действительно довольно тривиальная вещь, я бы предложил пойти на это. Если на сервере нет хотя бы нескольких ГБ памяти, я бы предложил придерживаться MySQL, а не использовать систему в памяти.

Как только вы начнете помещать свои данные в базу данных, будь то MySQL или что-то еще, вы, скорее всего, обнаружите, что вы найдете больше применений для них. Сейчас вы говорите только о парах ключ-значение, но остальные данные, относящиеся к вашим продуктам, должны где-то храниться. Если этого нет в базе данных, я не могу представить, чтобы хранилище данных было очень эффективным.

Что бы вы ни делали, не создавайте эти три миллиона файлов. Мы уже видели здесь несколько вопросов, возникающих из-за проблем, создаваемых многими файлами.

Вы можете использовать выделенный тип базы данных NoSQL Key-Value, который оптимизирован для такого рода задач. Посмотри на:

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

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

А сейчас нечто соверешнно другое:

Данный:

• 180MB / 3M продуктов = 62 байта / продукта в среднем.
• 30000 запросов в день = 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 очень широко (если не универсально) поддерживается на любом коммерческом веб-хосте. В зависимости от требуемой скорости, возможно, стоит рассмотреть memcached , но, не зная размера каждой пары ключ / значение, хранение 3 миллионов из них в памяти может оказаться даже хуже, чем файл CSV 180 Мб (о, подождите, это файл CSV 180 Мб, поэтому мы знаем, насколько они велики. Они должны быть довольно маленькими парами, поэтому memcached может быть еще лучше).

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

Вы можете использовать базу данных Berkeley, которая делает именно такие вещи, даже если она не была модной с момента появления Perl5. Беркли поддерживает только пары ключ-значение, и вы связываете всю базу данных с хешем и получаете к нему доступ как таковой.

Использование Berkeley подробно описано во многих старых ссылках на 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/

Несмотря на то, что 180 МБ данных могут быть легко обработаны любой реляционной базой данных, я настоятельно рекомендую MongoDB ( http://www.mongodb.org/) выше MySQL, Redis, MemcacheDB и других более простых хранилищ значений ключей или реляционных баз данных. Причина в том, что для такого рода проблем MongoDB является самой быстрой и наиболее выразительной системой, позволяющей выполнять сверхбыстрые динамические обновления без ограничений схемы, поэтому ваши документы могут иметь различные форматы, если вам это нравится. Я был на презентации от guardian.co.uk на днях, и они приняли политическое решение запретить все реляционные базы данных и использовать MongoDB исключительно для предоставления своих новостей. Вы можете почувствовать, насколько быстро работает их веб-сайт и который работает в сети с 1995 года (самая старая онлайн-газета в Великобритании). Они также прошли через все узкие места в прошлом из-за реляционных баз данных. Для 180 Мб MongoDB будет обслуживать все из памяти, поэтому время загрузки в субсекундах, вероятно, будет иметь место.

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

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

Я бы осмелился сказать, что все будет хорошо. Ваша нагрузка составляет 30000 запросов в день. Это означает, что (при условии, что ваша нагрузка постоянна в течение дня), у вас один запрос каждые 20 секунд; это не так уж плохо.

Я бы рекомендовал сначала внедрить технологию, с которой вы наиболее знакомы, а затем оценить, действительно ли это является узким местом системы.

Лучший способ сделать это действительно зависит от качества и характера ваших данных и запросов. Для начала, 180 МБ данных в одной таблице для продуктов - не проблема, как бы вы к ней ни относились. А 30 тыс. Запросов в день - это еще меньше проблем. С правильно настроенной базой данных любой старый рабочий стол может справиться с этой нагрузкой.

Другие уже указали два основных варианта: MySQL или база данных noSQL.

Если у вас есть определенное количество атрибутов, которые существуют для каждого отдельного продукта (например, производитель, цена, номер склада и т. Д.), Тогда лучше всего иметь столбцы для этих атрибутов и преобразовать пары ключ / значение в формат плоской таблицы, с идентификатором продукта в качестве первичного ключа для этой таблицы. Это будет работать очень хорошо, даже если некоторые столбцы используются только половиной строк, поскольку для большинства продуктов вам потребуется всего лишь выполнить 1 запрос, чтобы получить все их атрибуты. это данные о продуктах, я думаю, вполне вероятно, что это структура ваших данных.

Если атрибуты сильно различаются по наличию и типу данных, то вам лучше использовать базу данных noSQL, которая обрабатывает этот сценарий более эффективно, чем традиционные базы данных SQL.

Что касается производительности: ранее я работал в компании, занимающейся электронной коммерцией, где долгое время веб-сайт получал данные с сервера MySQL. Этот сервер имел 2 ГБ оперативной памяти, общая база данных была ок. Сервер размером 5 ГБ и при максимальной загрузке сервер обрабатывает несколько тысяч запросов в секунду. Да, мы провели большую оптимизацию запросов, но это определенно выполнимо.