MongoDB - Каким будет лучший ключ Shard Key для хранения данных электронной почты для отслеживания пикселов

Question

В настоящее время мы отправляем электронные письма подписчикам в нашем рассылке. Это имеет пиксель отслеживания, который сопоставляется с файлом PHP, который затем вставляет данные в нашу базу данных SQL Server.

В настоящее время среднее значение для пиксельных вложений для отслеживания электронной почты составляет около 80 000 вставок в день. И около 800 000 вставок равны примерно 1 ГБ свободного места на жестком диске, поэтому 10 дней 1 ГБ данных.

В дополнение к этому у нас есть другие данные вставки и отслеживания, вставленные в базу данных SQL Server, которая также является той же базой данных, которую используют веб-сайты. Таким образом, для пространства, производительности, затрат на лицензирование и причин масштабирования по горизонтали и т. Д. Я хочу перенести данные аналитического отслеживания из базы данных SQL Server +, что этот аналитический файл отслеживания не нужен веб-сайту, поэтому я хочу переместить эти тяжелые вставки записи так что сайт DB это именно так.

Структура таблицы в момент

TrackingPixelId | UserId | Код | Средний | Источник | DateViewed | SessionId

9109616 | 1234 | 'BULLETIN120115' | 'email' | 'BULLETIN120115' | {datetime} | bf7e2f801 ...

Column Info

TrackingPixelId: PK Integer автоматическое приращение

UserId: Integer

код, Medium и Источник: Струны/VARCHARS

DateViewed: DateTime например, 2015-01-13 06: 18: 24.920

S essionId: например, fa5cac87896e1c7b423051fffdb836a6

Код и источник - это по сути то же самое, уникальный идентификатор Открытого почтового ящика электронной почты.

Итак, с точки зрения представления данных мы будем рассматривать объем открытых электронных писем. Поэтому ежедневные, еженедельные, ежемесячные и годовые отчеты, и нам не понадобятся отчеты, которые будут мгновенно создаваться с загрузкой записей в день, а просто с полной записью, но, возможно, сначала будут нужны самые последние данные.

Итак, учитывая все эти факторы, какой был бы лучший ключ осколка?

Answer 1

Прежде всего, я предостерег бы вас, чтобы вы не прыгнули в шрамы сразу. С вашим объемом данных вы должны иметь возможность установить единый набор реплик для вашего трафика. Реальная точка запуска для ошпаривания - это когда рабочий набор становится больше, чем разумно для ОЗУ на одной машине.

При этом, учитывая, что вы в основном озабочены производительностью записи и будете терпеть более медленные чтения для отчетности, я думаю, что хешированный ключ осколка будет работать лучше всего. Вы можете использовать какой-либо уникальный идентификатор или хеш значение ObjectId, генерируемое MongoDB. Это гарантирует, что записи распределяются равномерно через кластер. Чтения будут собираться с разбросом, но похоже, что это приемлемо, чтобы получить очень хорошее масштабирование записи.

Плюс, поскольку вы заинтересованы в создании ежедневных, еженедельных, ...отчетов, я думаю, вы можете использовать стратегию hierarchical aggregation, чтобы минимизировать и амортизировать нагрузку на чтение, что для кластера будет намного более дорогостоящим, чем загрузка на запись из-за выбора ключа осколка. Это позволит вам постепенно генерировать отчеты по новым данным и затем запрашивать готовый отчет без необходимости генерировать его во время запроса. Я также предлагаю использовать агрегированные конвейеры вместо map/reduce, чтобы генерировать отчетные данные, когда это возможно, хотя на странице руководства используется карта/сокращение.