Нужно собирать статистику в системе по работе с клиентами средствами MySQL можете не шутить про то, что лучше застрелиться.
Вопросов бы не возникло, если бы не то, что статистику нужно фильтровать по всем полям, которые есть у сущности клиента (10+ полей). Т.е. в обычном случае, если бы фильтров было всего пару (статус и т.п.), я бы просто писал в базу счетчики и не парился насчет объема хранимой информации.
Пробема в этих 10+ полях. Примерный кейс: начальник хочет посмотреть статистику по клиентам со статусом "продажа" за прошлый месяц, но только по клиентам, которые были добавлены в систему с сентября по ноябрь, имеющим значение поля field1 = 'foo', field2 = 1, field3 = 'bar'.
Первое, что пришло в голову - это копипастить список клиентов в таблицу\таблицы со статистикой ежеминутно (для актуальности). В 00:00 стирать все записи за прошедший день до 23:59. В итоге остается один набор данных с актуальной информацией на прошедший день.
Подводный камень - это объем. При запуске нужно будет стартовать с 6000 записей сущности "клиенты". И каждый день количество клиентов будет только расти. Максимальный прирост с замком, граалем, статуей легиона - 80 в день. 6000+i*80 (записей) * 30 (дней) * 12 (месяцев) = close to bigdata. Через пару месяцев боюсь, что запросы в таблицу совсем замедлятся.
Вопросы: -правилен ли мой подход в данном случае? -какие есть возможности апгрейда (репликация\индексация\...)?
Я очень боюсь медленных запросов. А потому даже были мысли приземлить это все на какой-нибудь hadoop. Но это еще не BigData, знаю. Люди говорят, что 600M+ записей даже норма для MySQL.