Альтернатива или успех для GDBM

Question

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

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

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

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

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

2. Переместить в другую базу данных ключа, такую ​​как memcachedb или Tokyo Cabinet.

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

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

Answer 1

Не слишком зависеть от сравнения «реляционные и нереляционные». По-видимому, это не имеет значения для этой проблемы.

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

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

Answer 2

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

Answer 3

Если вы хотите придерживаться нереляционных баз данных, вы можете попробовать BDB или DJB's CDB. Я использовал оба до сих пор, и я думаю, что когда дело доходит до производительности, они превосходят GDBM.

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

Answer 4

Файловая система ввода/вывода с плоскими файлами по сети - не очень хорошая идея, но вам стоит подумать о написании многопоточного tcp-сервера, который делает i/o, query и т. Д. на этой машине, а затем возвращает результаты. Передайте небольшие куски данных не целые файлы db.

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