Здравствуйте. Сейчас работаю над проектом, в котором предполагается сбор большого количества данных (статистика). Нужно определиться со средствами и общей архитектурой. В качестве основной базы будем использовать Postgres (т.к надежнее, свободнее, чище SQL, присутствуют NoSQL фичи), в качестве бекенда PHP и ZF1. Так как сервис предполагает огромный поток данных (больше конечно запись, но и чтение тоже присутствует), я подумал, что имеет смысл создать некую прослойку между клиентом и основной базой, для горячих данных (очевидно, что свежие данные будут пользоваться бОльшим спросом, нежели архивные). Присматриваюсь к Redis, т.к пишут, что он уж очень быстр и позволяет хранить данные на диске, а не только в памяти. Собственно, есть идея хранить горячую статистику в Redis, а по истечении, скажем, месяца, переносить это все дело в архив в основную базу, в отдельную таблицу в Postgres, и Redis, соответственно, очищать. Хочу узнать совета профи, нормальное ли это решение или есть какие-нибудь другие лучшие варианты?
Анатолий K: какой-то непонятный негатив. я изложил свои мысли, я изложил суть, попросил оценить и дать совет. вроде как тостер это место, где дают советы, разве нет?
Анатолий K: если вам нечего сказать, то лучше ничего не говорить. задаю вопрос не с целью получить конкретный ответ, а с целью узнать какие средства люди посоветуют, погуглить, сравнить и прочее.
Вы определитесь с объемом горячих данных, наверняка он поместится в оперативку, и pоstgresql будет спокойно эти данные оттуда выбирать, не глупая же субд.
И предусмотрите шардинг сразу. Заложите изначально масштабирование.
Горячие данные и архив по-любому надо хранить в разных таблицах.
В таблицах, нацеленных только на запись, и редкое чтение, вероятно есть смысл совсем не использовать индексы, чтобы они не обновлялись при добавлении новых записей.
А потом проверите всё под нагрузкой, посмотрите цифры и решите нужен вам редис или нет. Postgres же умеет в оперативке данные кешировать, поэтому надо тестировать конкретно ваш прототип.
Средний
Простой
