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

Question

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

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

Спасибо :) Thomas

---

edit

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

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

Я попытаюсь поднять быструю сетевую архитектуру

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Но я сказал все это, чтобы поощрить вас распределить свои крылья в использование базы данных In memory для вашего сервера вместо того, чтобы сосредоточиться на использовании вашего архива. В этом случае вы ничего не сказали, что заставляет меня думать, что СУБД не лучшее решение для архивирования.

Answer 3

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

Answer 4

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

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

Я бы порекомендовал вам взглянуть на eXist dB и Mongo DB

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