Я работаю над проблемой IR, которая может быть представлена двумя таблицами ключ-значение.
Таблица Q: имеет фиксированный размер, определенный во время вставки, обновления счетчиков приращения таблицы, размер может изменяться по мере того, как данные кодируются в буферах протокола, а по мере увеличения числа они могут увеличивать размер байта (вариант int encoding).
Таблица P: содержит ссылки на таблицу Q, это отношение один ко многим, так как один p может указывать на множество q.Обновления увеличивают счетчики и добавляют ссылки.Много фрагментации.
Таблицы Q и P абсолютно одинаковы в характеристиках доступа к данным для стандартной структуры полнотекстового поиска IR инвертированных индексов.Q - документы, а P - слова - публикации.
Я пробовал следующие встроенные базы данных.
- Нормализованная форма SQLite, слишком медленная, не параллельная, слишком большая нагрузка на хранилище.Выполняет худшее.
- Киотодб.Производительность псевдотранзакций (глобальная блокировка) падает, линейно увеличиваясь после исходных 500 тыс. Строк.Перепробовал несколько разных подходов.
- Berkley db, транзакции заблокированные страницей, в памяти.Производительность становится неприемлемой после 6 миллионов строк исходного текста.Процессоры насыщены, но я ожидаю, что их использование будет зависеть от блокировок и спиновых блокировок.
- Leveldb (я сдался довольно быстро, он работает под блокировкой глобуса IIRC).Возможно, он сохраняет производительность записи.Я не позволил этому работать так долго.
Это тот случай, который я хочу оптимизировать:
- Время хранения / ЦП Предсказуемость.
- сверхвысокийскорость вставки.
- Последовательный, но не долговечный (асинхронная запись).
- Предназначен для параллельных вставок.
- Без Erlang и без Java.
И да, я могу при необходимости свернуть модель данных в документно-ориентированную структуру.Я ожидаю, что это будет обязательным для mongodb, поскольку транзакций нет.
Этот парень, похоже, знает, о чем говорит о , и, поскольку он дает mongodb 3 звезды в производительности вставки, яЯ довольно соблазн.Хотя Json кажется мне расточительным.Я также могу переключиться на сервер SQL, так как он удивителен при загрузке вставки, но он не масштабируется за пределами тяжелого железа. Итак, mongodb - это колени пчел для моего сценария, кто-нибудь пробовал гипертонизировать против mongodb?Другие рекомендации?
редактировать: самостоятельно ответить
предпосылка:
- Большие объемы транзакций являютсяdevil.
- Фрагментация - это дьявол.
Поэтому, прежде чем переходить к ориентированной на документы базе данных или распределенной базе данных значений ключей, в общем исправьте модель данных вашего приложения, чтобы лучше отобразить еемодели данных.Распределенные базы данных не имеют транзакций, и Mongo идет до атомарного обновления для одного документа - поэтому для использования обновления в рамках транзакции Q должен быть вашим документом, а P будет индексировать вариантные элементы в Q.
Итак, собираюсь переключиться на другое представление для моей модели данных.Я собираюсь удостовериться, что обе таблицы имеют статический размер в течение своего времени жизни (используя буферы протокола fixed32 вместо int32), кроме того, я собираюсь отключить (не инвертировать) таблицу P и с этой целью объединить большую часть P в Q.
Это позволит противостоять проблеме фрагментации, а также сократит объем транзакции, вставки в P могут быть выполнены вне транзакций.Я тоже собираюсь опробовать leveldb в гневе.У меня есть ощущение, что он будет поддерживать свой уровень производительности на протяжении всей обработки, не говоря уже о том, что он не будет распараллеливаться.