Кто-нибудь может предложить СУБД, которая является быстрой и эффективной при записи?

Question

У меня есть проект, который будет тяжелым для записи, а не для чтения. Мне было интересно, есть ли у кого-нибудь предложения по настройке СУБД с открытым исходным кодом, которые быстро записывают?

Это также не обязательно должна быть реляционная СУБД; Я открыт для предложений.

Answer 1

Я цитирую ниже некоторые части заключения NoSQL: если бы это было так просто (статья больше о масштабируемости, но все еще содержит интересные вещи, которые относятся к вашему контексту):

[...]

Реальная вещь, на которую следует обратить внимание, это то, что если вас удерживают от создания что-то супер круто, потому что ты не можете выбрать базу данных, вы делаете это неправильно. Если вы знаете mysql, просто используйте Это. Оптимизируйте, когда вам действительно нужно к. Используйте это как магазин K / V, используйте его как RDBMS, но ради бога, построить ваше убийственное приложение! Ничего из этого не будет имеет значение для большинства приложений. Facebook по-прежнему использует MySQL, много. Википедия использует MySQL много. FriendFeed использует MySQL, много. NoSQL - отличный инструмент, но конечно не будет твоим конкурентное преимущество, оно не собирается сделайте ваше приложение горячим, а главное, ваши пользователи не будут насмехаться этого.

Что я собираюсь построить в следующем приложении на? Вероятно, Postgres. Буду ли я использовать NoSQL? Может быть. Я мог бы также использовать Hadoop и улей. Я мог бы держать все в плоские файлы. Может быть, я начну взломать на Маглева. Я буду использовать все, что лучше для работы. Если мне нужна отчетность, я не буду использовать NoSQL. Если мне нужно Кэширование Тиран. Если мне нужна ACIDity, я не буду использовать NoSQL. Если мне понадобится тонна счетчиков, Я буду использовать Redis. Если мне нужно транзакции, я буду использовать Postgres. Если я есть тонна одного типа документы, я, вероятно, буду использовать Mongo. Если Мне нужно написать 1 миллиард объектов день, я бы, наверное, использовал Волдеморта. Если бы я нужен полнотекстовый поиск, наверное используйте Solr. Если мне нужен полнотекстовый поиск изменчивых данных, я бы, вероятно, использовал Sphinx.

[...]

Так что, если система хранения без ACID является опцией, я бы посмотрел на Voldemort . Если нет, то без более конкретной информации я не могу сказать, действительно ли одна СУБД лучше другой для приложений с интенсивной записью. На самом деле, я думаю, что это больше вопрос дизайна / архитектуры / настройки, и я склонен согласиться с автором: 1) использовать тот, который вы знаете больше всего 2) какой из них вы выберете, не будет иметь значения для большинства приложений.

Answer 2

Ну, я видел, как коммерческие БД получают по 2 ГБ в минуту на не особо впечатляющем оборудовании. Стандартные Open Source dbs (MySQL, Postgress и sqlite не сильно отстают).

Для любого объема записи, который вызовет проблемы с современной БД, есть три вещи, которые влияют на производительность (ни одна из которых не зависит от конкретной выбранной БД).

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

Два - размещение журнала или, если возможно, избегание журнала. Регистрация является узким местом в большинстве RDBM. Убедиться, что вы входите в систему на выделенных быстрых дисках, - это один из способов, включающий ведение журнала (зависит от СУБД, но большинство поддерживает это) для таблицы, если вы может позволить себе потерять транзакции.

Три - это аппаратное обеспечение: много памяти и много быстрых дисков для распределения нагрузки ввода-вывода.

Есть несколько экзотических вариантов, если это все еще недостаточно быстро. Купите мэйнфрейм z / OS и запустите почтенную IMS / DB с функцией DEDB (база данных ввода данных). Это примерно в четыре раза быстрее, чем любая другая БД ACID. Купите опцию Oracle In Memory DB (раньше это был HP TimesTen).

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

Answer 3

Системы баз данных могут быть оптимизированы в зависимости от среды, в которой они работают, но наиболее важным является аппаратный, особенно ввод / вывод. Используйте как можно больше дисков и настройте RAID 10 или RAID 0 + 1, так что вы не хотите рассчитывать проверку четности каждый раз, когда СУБД записывает что-либо на диск.

Answer 4

MongoDB должен быть хорош в этом. Посмотрите на этот пост особенно.

Answer 5

Это немного загадочный вопрос - если вы делаете много и много записей и очень мало просмотров (чтения) и (некоторых) обновлений) ...

Используйте файл произвольного доступа с фиксированной записью (Seek () и прочее на платформе posix), плоский файл. Если вам нужна индексация, просто индексируйте свои ключи в плоский файл для чтения и обновления.

Недостатком является необходимость синхронизации ключей. с содержанием на записи и обновления. Довольно простой C ++ или другой класс OO может справиться с этим для вас. Зачем писать индексы, если вы не собираетесь их использовать? И, в зависимости от ваших реальных потребностей, вы можете покончить с индексированием все вместе - И индексировать в конце дня или что-то-k !!

Ура, ш.

Answer 6

Определено «интенсивная запись»: миллиарды строк в день или интенсивная запись по сравнению с операцией чтения?

Даже "интенсивная запись" база данных достигает пика около 15% записи из-за индексов, проверки дубликатов, ОБНОВЛЕНИЯ .. ГДЕ и т. Д.

Если вы действительно не крайний случай (упомянутый в ответе NoSQL выше), подойдет любая СУБД, потому что пределом будет аппаратное обеспечение, а не поставщик.