Альтернатива или преемник GDBM - PullRequest
Новая
       49

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

4 голосов
/ 30 марта 2009

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

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

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

На мой взгляд, у меня есть следующие варианты:

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

  2. Перейти к другой базе данных значений ключей, например memcachedb или Tokyo Cabinet .

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

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

Ответы [ 4 ]

10 голосов
/ 30 марта 2009

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

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

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

2 голосов
/ 30 марта 2009

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

1 голос
/ 13 июля 2009

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

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

0 голосов
/ 20 февраля 2011

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

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

...