Хранение 200 миллионов строк переменной длины вызывает фрагментацию / раздувание таблицы

Question

Я пытаюсь сохранить более 200 миллионов пар ключ-значение.Значение более 50% ключей будет меняться в течение недели, и около 5% строк будут удалены без возможности восстановления.Использование традиционных решений SQL доказало, что это приводит к большой фрагментации, вызывает раздувание таблицы (в 4 раза больше исходного размера таблицы) и некоторые проблемы с производительностью.Для устранения этой фрагментации в SQL требуется значительное время.Мы использовали методы переиндексации и реорганизации, но оба не справились с фрагментацией.Кроме того, мне нужно скопировать эти данные на 2 другие системы, что также оказалось довольно проблематичным.

Конструкция таблицы проста:

ключ NVARCHAR (50)

value VARCHAR (MAX)

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

Есть ли у кого-нибудь какие-либо предложения о том, как мы можем решить эту проблему?по-другому, что может ограничить фрагментацию?

Answer 1

Возможно, есть способ создать механизм управления версиями и разделами даже в MSSQL:

Versioning : Если значение изменяется, старое значение помечается как is_active=False, и новое значение вставляется. Затем вы массово удаляете значения каждую неделю, что приведет к меньшей фрагментации в целом. Вы можете использовать представление для фильтрации только значений is_actvie=True.

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

Answer 2

MongoDb - это хороший выбор, так как он прост в настройке и администрировании, обеспечивает простое горизонтальное масштабирование (отличная поддержка шардинга) и легкую репликацию (с помощью наборов реплик).Производительность отличная, пока индексы помещаются в памяти.Однако MongoDb также подвержен фрагментации.С v2.0 теоретически можно управлять фрагментацией с помощью команды «compact».Чтобы сжимать базу данных без простоев, вам придется использовать репликацию, так как процесс будет:

• Для каждого набора реплик (осколок)
  • компактных ведомых устройств
  • пошаговый мастер
  • компактный мастер
  • (необязательно) возобновить оригинальный мастер

Вот пример сценария: https://github.com/mongodb/mongo-snippets/blob/master/js/compact-example.js

Answer 3

Это идеально подходит для MongoDb.

MongoDb также поддерживает ограниченные коллекции (которые вы можете использовать).Вы можете иметь объект в вашей БД, который в некотором смысле прокручивается, когда он вам больше не нужен.Что может уменьшить ваше администрирование базы данных, если ситуация меняется еженедельно.