Почему чтение из CouchDB происходит так медленно?(1,5 МБ / с или около того)

Question

У меня работает сервер CouchDB (1.1.1), который содержит много документов в диапазоне размеров 400-600 КБ.

Если я извлекаю полный документ из базы данных (не из вида, а только из необработанного документа), то для его завершения требуется 200-400 мс, что соответствует пропускной способности около 1,5 МБ / с.

Если я записываю те же данные в необработанные файлы на диске, они загружаются за 10-20 мс (около 25-50 МБ / с).

Я ожидаю, что CouchDB будет иметь некоторые издержки, но порядок (и некоторые) кажется безумным для того, что по сути является чтением!

Может кто-нибудь пролить свет на то, почему это может иметь место?

Обновление : как указано ниже, время от curl:

# time curl http://localhost:5984/[dbname]/[documentname]

real    0m0.684s
user    0m0.004s
sys     0m0.020s

Полученный документ был размером 642842 байта. Я протестировал его как на стандартном жестком диске объемом 1 ТБ, так и на экземпляре EC2 (том EBS) с похожими результатами.

Answer 1

Я думаю, что это несколько факторов

1. Вы выбираете через HTTP, который по сути является протоколом с более высокой задержкой. В частности, вы создаете TCP-соединение с нуля, используя curl. (Веб-браузеры и большинство клиентских программ поддерживают пул постоянных соединений HTTP / 1.1 keepalive.) Но в основном CouchDB выбирает «более медленный» протокол, потому что он настолько универсален и настолько стандартен.
2. Ваши документы имеют больший размер для CouchDB. Большинство документов представляют собой однозначные или двузначные КБ, а не тройные. CouchDB кодирует / декодирует этот JSON одним большим глотком (то есть он не транслируется с диска.)
3. Мало того, что ввод-вывод EC2 (даже EBS) менее чем идеален для базы данных (сама по себе имеет высокую задержку), но он также может колебаться, поскольку ваши соседи генерируют неизвестные пакеты ввода-вывода, с которыми вы конкурируете.
4. CouchDB - это файловая система поверх файловой системы. Файл .couch очень похож на саму файловую систему. Таким образом, вы умножаете неэффективность. Файл .couch и метаданные требуют случайного ввода-вывода против хранилища; и чтение документа требует случайного ввода-вывода в файле .couch. Вы можете увидеть влияние задержки диска. Вместо того, чтобы сравнивать чтение документа с чтением файла файловой системы, вы можете сравнить чтение документа с чтением эквивалентной строки MySQL.

Обратите внимание, я не говорю, что CouchDB на самом деле быстрый и ваши результаты неверны. Скорее наоборот: CouchDB работает медленнее, чем ожидают многие. В некоторой степени у него есть возможности для улучшения и оптимизации; но прежде всего CouchDB решила, что эти затраты стоят того, чтобы принести более широкую пользу.

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

Тем не менее, CouchDB является доменной базой данных , и поэтому может быть ясно, что вы ищете другой инструмент.

Answer 2

Как вы получаете документ? Если вы используете какой-то код, пожалуйста, включите этот код и все библиотеки, которые вы используете.

Или просто используйте curl, чтобы получить документ. Например, я просто набрал time curl http://localhost:5984/bwah/foo и получил документ в .017s. Важное замечание: я на машине с твердотельными накопителями.

Кроме того, одного чтения недостаточно, чтобы предположить пропускную способность, которую можно ожидать от CouchDB или любого серверного программного обеспечения в этом отношении. Вам нужно выполнить много запросов, а затем посмотреть среднее и среднее время.