Что такое хороший СУБД для архивирования?

Question

Я застрял в мире MSSQL/MySQL уже несколько лет, и я решил распространить свои крылья немного дальше. На данный момент я исследую, какие СУБД хороши для вещей, необходимых при архивировании данных. Например. Много записей и низких чтений.

Я видел крестовый поход NOSQL, но у меня очень много RDBMS, поэтому я немного скептически настроен.

У кого -нибудь есть предложения? Или даже какие -либо указатели на то, где есть некоторые тесты и т. Д. Для такого рода вещей.

Спасибо :) Томас

---

редактировать

Так как был вопрос, я постараюсь дать немного больше информации о том, что я думаю

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

Я попробую Ascii быстро сетевой архитектурой

     ___________    ___________    ___________
    | service 1 |  | service 2 |  | service 3 |
     -----------    -----------    -----------
          |____________|_______________|
                   ____|____
                  | Archive |
                   ---------

Как вы, возможно, знаете, MSSQL и MySQL масштабируются только по вертикали при работе с написанием (не уверены, что это вещь RDBMS). Так что я ищу максимум выступления из этого архивного СУБД, насколько это возможно.

Answer 1

Если структура данных, которые вы архивируете, относительно проста, вы можете рассмотреть архивирование непосредственно в плоские файлы. Хорошо для письма, не так хорошо для чтения. В этом вопросе есть некоторое обсуждение по этой теме: Являются ли базы данных плоских файлов?

В противном случае я буду придерживаться MySQL и убедиться, что он правильно настроен для использования с высоким содержанием записи/низкочитывания.

Answer 2

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

Во -первых, скорость запроса не является прямо пропорциональной размеру базы данных, если вы не выполняете только полные сканирования таблицы. Уникальный поиск индекса пропорционален глубине индекса. С момента того, как корневой блок индекса распадается до следующего, когда он расщепляется, может быть миллионы дополнительных строк. На самом деле удаление строк, чтобы удержать базу данных как можно более пустой »может фактически не сделать базу данных меньше. До тех пор, пока вы не восстановите индекс, у вас может быть очень разреженная ветвь и листовые блоки, делающие индекс, что займет больше времени и дольше.

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

В Oracle я бы посоветовал разбить и опустить удаление, чтобы фактически сохранить базу данных определенным размером.

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

Answer 3

Oracle или PostgressQL также очень мощные СУБД. Но если вы уже знаете и использовали MySQL, зачем меняться? MySQL бесплатный, исполняющий, хорошо документирован ...

Но если у вас в основном есть операции на записи, а не много чтения, и вам больше не хотите широко используемых СУБД, то вы можете рассмотреть СУБД на основе документов

Я бы порекомендовал вам взглянуть на существует DB а также Mongo DB

Надеюсь это поможет!

Answer 4

Вы можете увидеть результат чтения/записи результата разнообразной базы данных с этим Программное обеспечение для базы данных Benchmark (GNU GPL)Это подходит найти некоторые ответы.