Альтернатива или преемник GDBM

Question

У нас есть ГДБМ база данных «ключ-значение» в качестве серверной части веб-приложения с балансировкой нагрузки, реализованного на C++.Данные, обслуживаемые приложением, стали очень большими, поэтому наши администраторы переместили файлы GDBM из «локального» хранилища (на веб-серверах или очень близко) в большую, общую, удаленную файловую систему, смонтированную по NFS.

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

Хотя это не критичное приложение, я хотел бы улучшить производительность и иметь в наличии некоторые ресурсы, включая время разработчика приложения и администраторов Unix.Мое главное ограничение — время, которого хватит только на несколько недель.

Как я понимаю, мои варианты:

1. Улучшите производительность NFS путем настройки параметров.Я инстинктивно подскажу, что мы многого от этого не получим, но раньше я ошибался и не особо разбираюсь в настройке NFS.

2. Перейдите в другую базу данных «ключ-значение», например memcachedb или Токийский кабинет.

3. Замените NFS каким-нибудь другим протоколом (упоминался iSCSI, но я с ним не знаком).

Как мне подойти к этой проблеме?

Answer 1

Не зацикливайтесь на сравнении «реляционных и нереляционных».Кажется, это не имеет значения для данного вопроса.

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

За то, что все быстро заработало, МарияДБ (преемник MySQL), вероятно, лучший выбор.Если вы предвидите, что он вырастет намного дальше того, что есть сейчас, вы могли бы также поместить его в PostgreSQL так как именно туда в любом случае придется идти :-)

Answer 2

Кажется, это не то, что вы хотите услышать, но, честно говоря, на вашем месте я бы добавил это в таблицу MySQL.Это не значит, что с ним значительно сложнее работать, и вы получаете много преимуществ, не в последнюю очередь протокол удаленного доступа, который действительно предназначен для вашей ситуации, в отличие от GDBM-over-NFS.

Answer 3

Если вы хотите использовать нереляционные базы данных, вы можете попробовать БДБ или DJB ЦКБ.До сих пор я использовал оба варианта и думаю, что по производительности они превосходят GDBM.

Но помните об ответе bignose, поскольку я тоже думаю, что вашим узким местом может быть не структура данных (GDBM), которую вы используете, а ваша инфраструктура.

Answer 4

Ввод-вывод файловой системы с плоскими файлами по сети — не очень хорошая идея, но вам следует подумать о написании многопоточного TCP-сервера, который выполняет ввод-вывод, запросы и т. д.на этой машине, а затем возвращает вам результаты.Передавайте небольшие фрагменты данных, а не целые файлы БД.

Я разрабатываю механизм сохранения кэша для решения проблемы высокой доступности. Я напишу его на Python.