Параллелизм BerkeleyDB

Это зависит от того, какое приложение вы создаете. Создайте репрезентативный тестовый сценарий и приступайте к работе. Тогда вы будете знать окончательный ответ.

Помимо вашего варианта использования, он также зависит от CPU, памяти, передней шины, операционной системы, настроек кэша и т. д.

Серьезно, просто проверьте свой собственный сценарий.

Если вам нужны какие-то цифры (это на самом деле может ничего не значить в вашем сценарии):

• Oracle Беркли DB: Показатели производительности и Стандарты
• метрики производительности & контрольные показатели:
  Беркли DB

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

Кроме того, это общие факторы, которые, как я обнаружил, оказывают существенное влияние на пропускную способность:

1. Метод доступа (который в вашем случае, я думаю, составляет BTREE).

2. Уровень персистентности, с которым вы настроили DBD (например, в моем случае флаг среды 'DB_TXN_WRITE_NOSYNC' улучшил производительность записи на порядок, но это ставит под угрозу персистентность)

3. Помещается ли рабочий набор в кэш?

4. Количество операций чтения и записи.

5. Как распределен ваш доступ (помните, что BTREE имеет блокировку уровня страницы - так что доступ к разным страницам с разными потоками является большим преимуществом).

6. Шаблон доступа-означает, насколько вероятно, что потоки будут блокировать друг друга, или даже взаимоблокировки, и какова ваша политика разрешения взаимоблокировок (это может быть убийцей).

7. Аппаратное обеспечение (дисковая & память для кэша).

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

Разве это не зависит от оборудования,а также количества потоков и прочего?

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

При работе с базой данных с неизвестной производительностью я измерял время выполнения своих запросов. Я продолжал увеличивать количество потоков до тех пор, пока время поворота не уменьшилось, и уменьшал количество потоков до тех пор, пока время поворота не улучшилось (ну, это были процессы в моей среде, но все равно).

Там были скользящие средние и всевозможные метрики, но урок на вынос был таков: просто адаптируйтесь к тому, как все работает в данный момент. Вы никогда не знаете, когда DBAs улучшит производительность или оборудование будет обновлено, или, возможно, появится другой процесс, чтобы загрузить систему во время работы. Так что адаптируйся.

Да, и еще одно: избегайте переключений процессов, если вы можете-пакетные вещи.

О, я должен прояснить это: все это произошло во время выполнения, а не во время разработки.

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

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