бизнес фон
Как показано на рисунке, функция анализа удержания пользователей
анализ спроса
На этой гистограмме показан процент удержанных пользователей.
Возьмем в качестве примера недельный показ
U: количество активных пользователей x: неделя y: доля активных пользователей
Организация потребностей:
- По дням, по неделям, по месяцам Сравнение трех фиксированных дат
- Выбор даты Сравнение случайных дат
Для этой серверной функции данных, какРазработка сервера, мы сделаем все возможное, чтобы запросить базу данных для подсчета результатов, и наш сервер будет напрямую извлекать результаты для отображения.
Однако из-за сравнения случайных дат предполагается, что статистика выполняется по группе данных, а это означает, что необходимо делать сравнение статистики каждый день (статистические результаты имеют большой объем данных и потребляют производительность). , что не реально.
В итоге было решено вести статистику в реальном времени сервером.
Статистика в реальном времени, в основном с учетом скорости отклика внешнего интерфейса.
Вариант 1. Храните информацию о входе пользователя в измерение дня.
Используйте растровое изображение для хранения данных входа пользователя по дням и широте.
Процесс реализации:
- Предполагаемое общее количество пользователей составляет 400 миллионов, и для использования хранилища растровых изображений требуется около 50 миллионов.
- Сортировка пользователей, простая реализация: самоинкремент id в таблице хранения (пока без учета эффективности таблицы хранения)
- Каждый день авторизованные пользователи генерируют растровое изображение
- При вычислении y(x(i)), вам нужно только извлечь растровые изображения x(1) и x(i) для выполнения операции AND, затем подсчитать количество полученных единиц и разделить на растровое изображение x( i) что 1 число
Вариант 2. Храните информацию о времени входа пользователя в пользовательский параметр.
Используйте растровое изображение для хранения информации о времени входа в систему в соответствии с широтой пользователя (в какие дни входить в систему).
-
Запишите текущий день как стандартный день 0
-
Для каждого вошедшего в систему пользователя, для каждого вошедшего в систему пользователя установите позицию, соответствующую текущему количеству дней, на 1
-
При вычислении y(x(i))
Пользователь описывать bitmap a Вход в день -4,-3,-1,0 [1,1,0,1,1] b Вход в день -3,-2,0 [1,1,0,1] B(-3,0) Вход в день -3,0 [1,0,0,1] B(0) Вход в день 0 [1] - Обход a, b и B(1,4) для выполнения и операции, статистический результат == количество B(1,4), то есть количество вошедших в систему пользователей за 1, 4 дня
- Затем сделайте то же самое, чтобы получить количество вошедших в систему пользователей на 4-й день, и разделите, чтобы получить результат.
| преимущество | недостаток | |
|---|---|---|
| Вариант первый | Быстрый запрос, нужно выполнить только одну операцию | Пространство слишком велико, и каждый день создается растровое изображение с максимальным количеством пользователей. |
| Вариант 2 | Экономьте место, занимаемое пространство увеличивается с количеством пользователей, а растровое изображение каждого пользователя меняется в зависимости от ситуации входа в систему. | Запрос немного медленнее и должен пройти через всех пользователей, чтобы сделать и операции |
Краткое резюме: план один требует места, план два требует много времени для запросов
В реальном процессе разработки, потому что мы используем Redis для хранения.
Если вы используете схему 1, то память слишком расточительна.Со схемой 2 моя конфигурация macpro-i5 может загрузить только 20w/s и работу, а скорость отклика неприемлема.
Комбинация вышеперечисленных методов один или два не может удовлетворить требования, только для того, чтобы посмотреть, есть ли еще место для оптимизации.
После того, как коллеги напомнили,алгоритм сжатия пространства, чтобы решить проблему космических отходов в первом решении.
Сценарий 3: ИспользованиеRoaringBitmapХранить информацию о входе пользователя в дневное измерение
Введение в RoaringBitmap смотрите здесь
Краткое содержание:
-
Предположим, что объем данных не превышает 2^32.
-
Разделить данные на старшие 16 бит и младшие 16 бит
-
Агрегировать старшие биты (использовать старшие биты в качестве ключа, а значением являются все младшие массивы с одинаковыми старшими битами)
-
В зависимости от количества младших данных (длина младших массивов, агрегированных разными старшими битами, различна), используйте разные контейнеры (структуры данных) для хранения
-
len
-
len>=4K BitmapContainer использует хранилище растровых изображений
4K的取值原因:value的最大总数是为2^16=65536. 假设以bitmap方式存储需要65536bit=8kb,而直接存值的方式,一个值16,4K个总共需要2byte*4K=8kb.所以当value总量<4k时,使用直接存值的方式更节省空间 -
Сжатое хранилище RunContainer
RunContainer中的Run指的是行程长度压缩算法(Run Length Encoding)，对连续数据有比较好的压缩效果.对于数列11,12,13,14,15,21,22 它会压缩为11,4,21,1- Оптимально, массив значений полностью сплошной, тогда будут храниться только 2 шорта, занимающих 4кб
- В худшем случае массив значений будет полностью прерывистым (все нечетные/все четные), тогда в нем будет храниться 65536 шортов, 128 КБ.
-
-
Сжатие пространства в основном проявляется в:
- Агрегация высокого порядка (при условии, что в данных имеется 100w значений высокого порядка с одинаковым значением, изначально требовалось 100w*2 байта, но теперь требуется только 1*2 байта)
- Низкобитное сжатие (ArrayContainer экономит место, BitmapContainer не сохраняет, RunContainer может экономить)
-
Это влияет на скорость битовой обработки данных (три контейнера взаимно и. В оптимистичном случае два BitmapContainers делают и обрезают BitCount ()> 4096, тогда данные не влияют)
Подводя итог: преимущества и недостатки использования RoaringBitmap
- Экономия места (высокий порядок оптимального набора данных одинаков, а старший порядок наихудшего набора данных другой)
- Скорость битовых операций снижена для собственного растрового изображения.
Можно сказать, что вариант 3 уравновешивает варианты 1 и 2 и на этот раз является лучшим выбором.