BerkeleyDB Concurrency

Какой оптимальный уровень concurrency, который может поддерживать поддержка С++ в BerkeleyDB?
Сколько потоков я могу ударить в БД, прежде чем пропускная способность начнет страдать из-за конфликта ресурсов?

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

Мое приложение довольно простое, я буду зарабатывать и записывать записи размером около 1 КБ. Нет курсоров, без удаления.

Ответ 1

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

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

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

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

Ответ 2

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

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

Метод доступа (который в вашем случае, я думаю, имеет значение BTREE).
Уровень стойкости, с которым вы настроили DBD (например, в моем случае флаг среды "DB_TXN_WRITE_NOSYNC" улучшил производительность записи на порядок, но это ставит под угрозу постоянство)
Соответствует ли рабочий набор в кеше?
Число чтений Vs. Пишет.
Как распространяется ваш доступ (помните, что BTREE имеет блокировку на уровне страницы, поэтому большое преимущество имеет доступ к различным страницам с разными потоками).
Шаблон доступа - означает, насколько вероятны потоки для блокировки друг друга или даже взаимоблокировки, и какова ваша политика разрешения блокировки (это может быть убийца).
Оборудование (диск и память для кеша).

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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