Не думаю, что это ужасная идея.
Давайте рассмотрим сценарий подключения / месяца.
Учитывая, что длина записи составляет ~ 40 (это достаточно) символов, и вы получаете ~ 8 200 записей в месяц, ваш конечный размер документа будет составлять ~ 350 КБ в конце месяца.
Это означает, что, работая на полную катушку, вы будете читать и писать 2000 350 тыс. Документов каждые 5 минут.
Ввод / вывод, это меньше, чем 6 МБ / с, учитывая чтение и запись, усредненные для 5-минутного окна времени. Сегодня это хорошо даже для низкоуровневого оборудования.
Однако есть и другая проблема. Когда вы сохраняете этот документ, Couch будет оценивать его содержимое, чтобы построить его представление, поэтому Couch будет анализировать 350K документов. Я боюсь, что (в конце концов, но прошло уже какое-то время), я не верю, что Couch хорошо масштабировался по ядрам процессора, поэтому это может легко закрепить одно ядро процессора, которое будет использовать Couch. Я хотел бы надеяться, что Couch может читать, анализировать и обрабатывать 2 МБ / с, но я, честно говоря, не знаю. Несмотря на все свои преимущества, erlang - не самая лучшая попка на прямолинейном компьютерном языке.
Последняя проблема - идти в ногу с базой данных. Это будет писать 700 МБ каждые 5 минут в конце месяца. С архитектурой Couchs (только добавление) вы будете записывать 700 МБ данных каждые 5 минут, что составляет 8,1 ГБ в час, и 201 ГБ через 24 часа.
После сжатия БД он сокращается до 700 МБ (в течение одного месяца), но в течение этого процесса этот файл будет становиться большим и довольно быстрым.
Что касается извлечения, эти большие документы меня не пугают. Загрузка документа JSON 350 КБ, да, он большой, но не такой большой, не на современном оборудовании. На досках объявлений больше аватаров. Так что все, что вы хотите сделать относительно активности соединения в течение месяца, будет довольно быстрым, я думаю. Через соединения, очевидно, чем больше вы захватываете, тем дороже это будет (700 МБ для всех 2000 соединений). 700MB - это реальное число, которое оказывает реальное влияние. Кроме того, ваш процесс должен быть агрессивным при отбрасывании данных, которые вам не нужны, поэтому он может отбросить мусор (если вы не хотите загружать 700 МБ кучи в процессе вашего отчета).
С учетом этих чисел соединение / день может быть лучшей ставкой, поскольку вы можете немного лучше контролировать гранулярность. Однако, честно говоря, я бы пошел на самый грубый документ, который вы можете, потому что я думаю, что это дает вам наибольшую выгоду из базы данных, только потому, что сегодня все поиск головок и ротация дисков - это то, что снижает производительность ввода-вывода, много дисков потоковые данные очень хорошо. Документы большего размера (при условии, что данные расположены правильно, поскольку Couch постоянно уплотняется, это не должно быть проблемой) передаются больше, чем поиск. Поиск в памяти "свободен" по сравнению с диском.
Во что бы то ни стало запустите свои собственные тесты на нашем оборудовании, но примите все эти соображения близко к сердцу.
EDIT:
После дополнительных экспериментов ...
Пара интересных наблюдений.
При импорте больших документов процессор одинаково важен для скорости ввода-вывода. Это происходит из-за количества маршаллинга и процессора, потребляемых при преобразовании JSON во внутреннюю модель для использования представлениями. При использовании больших (350 тыс.) Документов мои процессоры были в значительной степени загружены (350%). Напротив, с меньшими документами они гудели на 200%, хотя, в целом, это была та же самая информация, просто разбитая на части по-разному.
Для операций ввода-вывода при 350К документах я составлял 11 МБ / с, но с меньшими документами это было только 8 МБ / с.
Сжатие оказалось почти связанным с вводом / выводом. Мне трудно получить хорошие цифры о моём потенциале ввода / вывода. Копия кэшированного файла отправляет 40 + МБ / с. Уплотнение работало со скоростью около 8 МБ / с. Но это согласуется с необработанной загрузкой (при условии, что couch перемещает сообщение сообщение за сообщением). Процессор ниже, так как он выполняет меньше обработки (он не интерпретирует полезные нагрузки JSON и не перестраивает представления), плюс это был один процессор, выполняющий эту работу.
Наконец, для чтения я попытался выгрузить всю базу данных. Один процессор был привязан для этого, и мой ввод / вывод довольно низкий. Я хотел убедиться, что файл CouchDB на самом деле не был кэширован, на моей машине много памяти, поэтому многие вещи кэшируются. Необработанный дамп через _all_docs составлял всего около 1 МБ / с. Это почти все поиски и задержки вращения, чем все остальное. Когда я делал это с большими документами, скорость ввода-вывода достигала 3 МБ / с, что просто показывает эффект потоковой передачи. Я упомянул преимущество для больших документов.
И следует отметить, что на веб-сайте Couch есть методы улучшения производительности, которыми я не следовал. Примечательно, что я использовал случайные идентификаторы. Наконец, это было сделано не для того, чтобы оценить производительность Couch, а там, где нагрузка заканчивается. Большие различия по сравнению с небольшими документами, которые мне показались интересными.
Наконец, конечная производительность не так важна, как просто хорошая производительность для вашего приложения с вашим оборудованием. Как вы упомянули, вы проводите собственное тестирование, и это все, что действительно имеет значение.