Я не думаю, что это ужасная идея.

Давайте рассмотрим ваш сценарий "подключение/месяц".

Учитывая, что длина записи ~40 (это щедро) символов, и вы получаете ~8,200 записей в месяц, ваш конечный размер документа будет ~350K в конце месяца.

Это означает, что, работая в полную силу, вы будете читать и записывать 2000 350K документов каждые 5 минут.

С точки зрения ввода-вывода, это менее 6 МБ/с, учитывая чтение и запись, в среднем за 5 м времени. Это вполне приемлемо даже для современных аппаратных средств низкого класса.

Однако есть и другая проблема. Когда вы сохраняете документ, Couch собирается оценить его содержимое, чтобы построить представление, поэтому Couch будет разбирать 350K документов. Я боюсь, что (по последней проверке, но прошло уже некоторое время) я не верю, что Couch хорошо масштабируется по ядрам CPU, так что это может легко привести к тому, что Couch будет использовать одно ядро CPU. Я бы хотел надеяться, что Couch сможет читать, разбирать и обрабатывать данные со скоростью 2 МБ/с, но я, честно говоря, не знаю. При всех своих преимуществах, erlang - не самый лучший язык для работы с компьютером.

Последняя проблема - это поддержка базы данных. Это будет запись 700 МБ каждые 5 минут в конце месяца. С архитектурой Couchs (только добавление), вы будете записывать 700 МБ данных каждые 5 минут, что составляет 8,1 ГБ в час, и 201 ГБ через 24 часа.

После сжатия DB он уменьшится до 700 МБ (для одного месяца), но во время этого процесса файл будет становиться большим, и довольно быстро.

С точки зрения ретривера, эти большие документы меня не пугают. Загрузка документа JSON размером 350K, да, он большой, но он не настолько большой, не на современном оборудовании. На досках объявлений есть аватары и побольше. Так что все, что вы хотите сделать относительно активности соединения за месяц, будет довольно быстро, я думаю. Что касается всех подключений, очевидно, что чем больше вы захватываете, тем дороже это будет стоить (700MB для всех 2000 подключений). 700 МБ - это реальное число, которое имеет реальное влияние. Плюс ваш процесс должен быть агрессивным в отбрасывании данных, которые вас не интересуют, чтобы он мог отбросить мякину (если вы не хотите загрузить 700 МБ кучи в вашем процессе отчета).

Учитывая эти цифры, Connection/Day может быть лучшим вариантом, поскольку вы можете лучше контролировать детализацию. Однако, честно говоря, я бы выбрал самый крупный документ, который вы можете, потому что я думаю, что это даст вам лучшую ценность от базы данных, только потому, что сегодня все поиски головки и вращение пластины - это то, что убивает большую часть производительности ввода-вывода, многие данные дискового потока очень хороши. Большие документы (при условии хорошо расположенных данных, поскольку Couch постоянно уплотняется, это не должно быть проблемой) передают больше, чем ищут. Поиск в памяти "бесплатен" по сравнению с диском.

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

EDIT:

После дополнительных экспериментов...

Пара интересных наблюдений.

При импорте больших документов CPU не менее важен, чем скорость ввода/вывода. Это связано с количеством маршалинга и потреблением CPU при преобразовании JSON во внутреннюю модель для использования представлениями. При использовании больших (350k) документов, мои CPU были практически максимально загружены (350%). Напротив, при использовании документов меньшего размера они работали на 200%, хотя в целом это была одна и та же информация, просто разбитая на куски по-разному.

Для ввода/вывода, при работе с 350-килобайтными документами я показывал скорость 11 МБ/с, а при работе с документами меньшего размера - только 8 МБ/с.

Оказалось, что уплотнение почти не связано с вводом-выводом. Мне трудно получить точные цифры о моем потенциале ввода-вывода. Копия кэшированного файла работает со скоростью 40+МБ/сек. Уплотнение работает со скоростью около 8 МБ/с. Но это соответствует необработанной нагрузке (если предположить, что couch перемещает материал сообщение за сообщением). CPU ниже, так как он выполняет меньше обработки (он не интерпретирует полезную нагрузку JSON и не перестраивает представления), плюс это был один CPU, выполняющий работу.

Наконец, для чтения я попробовал выгрузить всю базу данных. Для этого был задействован один процессор, а мой ввод/вывод был довольно низким. Я убедился, что файл CouchDB не был кэширован, у моей машины много памяти, поэтому многие вещи кэшируются. Необработанный дамп через _all_docs был всего около 1 МБ/с. Это почти все задержки поиска и вращения, чем что-либо еще. Когда я делал это с большими документами, скорость ввода/вывода достигала 3 МБ/с, что просто показывает влияние потоковой передачи, о котором я говорил, как о преимуществе для больших документов.

И следует отметить, что на сайте Couch есть методы повышения производительности, которым я не следовал. В частности, я использовал случайные идентификаторы. Наконец, это не было сделано для оценки производительности Couch, а скорее для определения того, где нагрузка оказывается в конечном итоге. Разница между большим и маленьким документом показалась мне интересной.

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