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

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

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

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

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

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

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

• Oracle Berkeley DB: Показатели производительности и Контрольные точки
• Показатели эффективности & Тесты:
  Berkeley DB

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

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

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

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

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

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

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

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

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

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

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

4. Количество прочтений по сравнению с Пишет.

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

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

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

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