Выбор базы данных: высокая запись, низкая читаемость

Question

Я создаю компонент для записи исторических данных. Первоначально я ожидаю, что он будет выполнять около 30 операций записи в секунду и менее 1 операции чтения в секунду.

Данные никогда не будут изменены, будут добавлены только новые данные. Чтения, вероятно, будут сделаны со свежими записями.

Спрос может быстро возрасти, ожидая около 80 операций записи в секунду за один год.

Я мог бы распределить свой компонент и использовать общую базу данных, такую ​​как MySql, или я мог бы использовать распределенную базу данных, такую ​​как MongoDb. В любом случае, я бы хотел, чтобы база данных хорошо справлялась с записями.

База данных должна быть бесплатной. Открытый источник будет плюсом: -)

Примечание. Запись представляет собой простой текст переменного размера, обычно от 50 до 500 слов.

Answer 1

Ваш вопрос может быть решен несколькими различными способами, поэтому давайте разберем его и рассмотрим индивидуальные требования, которые вы изложили:

1. Запись - Похоже, большая часть того, что вы делаете, - это добавление записи только при относительно низкой громкости (80 операций записи в секунду). Практически любой продукт на рынке с разумным внутренним хранилищем сможет справиться с этим. Вы просматриваете 50-500 «слов» сохраняемых данных. Я не уверен, что составляет слово, но ради аргумента давайте предположим, что слово в среднем состоит из 8 символов, поэтому ваши данные будут представлять собой метаданные, ключ / метку времени / что угодно плюс 400-4000 байты слов. Если исключить конкретные детали реализации различных СУБД, это все еще довольно нормально, мы, вероятно, записываем самое большее (включая накладные расходы на запись) 4100 байт на запись. Максимальная скорость составляет 328 000 байт в секунду, или, как я бы сказал, не слишком много написания.

2. Удаляет - Вам также нужна возможность удалить ваши данные. Я не могу много сказать об этом. Удаляет удаляет.

3. Чтение - Здесь все становится сложнее. Вы упоминаете, что в основном это первичные ключи, и чтение выполняется на свежих данных. Я не уверен, что это означает, но не думаю, что это имеет значение. Если вы делаете поиск только по ключу (например, я хочу запись 8675309), тогда жизнь хороша, и вы можете использовать практически все.

4. Объединения - если вам нужна возможность записывать фактические объединения там, где их обрабатывает база данных, вы вычеркнули себя из основных продуктов нереляционной базы данных.

5. Размер данных / Data life - это то, где все становится веселее. Вы оценили свои записи в 80 в секунду, и я предполагаю, что 4100 байт на запись или 328 000 байт в секунду. В дне 86400 секунд, что дает нам 28 339 200 000 байт. Ужасающий! Это 3 351 269,53125 КБ, 27 026 МБ или примерно 26 ГБ в день. Даже если вы храните данные в течение 1 года, это 9633 ГБ или 10 ТБ данных. Вы можете арендовать 1 ТБ данных у провайдера облачного хостинга примерно за 250 долларов США в месяц или купить у поставщика SAN, такого как EqualLogic, примерно за 15 000 долларов США.

Вывод: я могу думать только о нескольких базах данных, которые не могут справиться с этой нагрузкой. 10 ТБ становится немного сложнее и требует немного административных навыков, и вам, возможно, придется взглянуть на определенные методы управления жизненным циклом данных, но почти любая СУБД должна быть справлена ​​с этой задачей. Аналогично, почти любая нереляционная / NoSQL база данных должна соответствовать этой задаче. На самом деле, практически любая база данных любого рода должна соответствовать поставленной задаче.

Если вы (или члены вашей команды) уже обладаете навыками в конкретном продукте, просто придерживайтесь этого. Если в вашей проблемной области есть конкретный продукт, используйте его.

Это не та проблема, для которой требуется какой-либо распределенный волшебный порошок единорога.

Answer 2

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

Индексы оптимизируют чтение, но уменьшают возможности записи.

Вы также можете использовать PostgreSQL. Там, где вам также нужно пропустить индексы, но у вас не будет выбора движка, и его возможности также очень хороши для записи.

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

Вы должны взглянуть и обратиться к Oracle Express (я думаю, это его название) и к SQL Server Express Edition. Последние два имеют лучшую производительность, но также и некоторые ограничения. Чтобы иметь более подробную картину.