Eugene Usachev, эммм. Не совсем понятно что вы хотите с блокировками. Если пользователь отправил в чат сообщение раньше чем его забанили - то оно должно появится в чате.
Виталий Артемьев,
1. Postgres умеет сжимать таблицы. Можете прописать сжатие для table space - в том числе и Lz4 как у кликхауса.
2. Сравнивать ваш кейс с таблицами и текущий кейс немножко не правильно. Ибо исходя из MVCC который в Postgres запросик вида update table set field = field; и Posgtres весело увеличит вам таблицу в 2 раза, до следующего автовакуума, не смотря на то что вроде как бы в таблице ничего не помнялось. По этому сравнивать надо не только данные, но то что вы с ними делаете - результат будет весьма различен. В этой задачи я большого количества update не вижу, поправьте меня если я не прав.
3. Почему clickhouse отдает данные быстро. Я уж лет 5 как с ним не работал, может чего поменялось, может я чего забыл, но:
a) Колоночная бд - колонки лежат в отдельных файлах. По этому запрос select field from table будет в Clickhouse быстрее чем в Postgres. Однако верно и обратное ворочать запрос вида select * from table в Postgres будет легче нежели в Clickhouse. У вас есть уверенность что первый вариант в этой задаче будет превалировать над втором? Я в этом не уверен, но с удовольствием вас выслушаю
b) Разряженный индекс вместо плотного. В Clickhouse разреженный индекс - узел индекса ссылается не на 1 запись, а на n-цать, и читает Clickhouse гранулами насколько я помню. Posgtres страницами. По этому запрос select user_id from reviews where primary between 100000 and 30000000 прекрасно отработает в Клихаусе. Верно и обратное - запрос select * from reviews where primary = 1 отработает там хуже - потому что клихаус будет искать 1 запись в грануле. Если у вас есть увереность что большая часть запросов которая в этой задаче будет соотвествовать первому варианту?
с) данные в clickhouse хранятся упорядоченно согласно первичному ключу - последовательное чтение обычно быстрее случайного. Когда вы используете clickhouse для записи каких то событий - то вообще огонь потому что события обычно идут друг за другом и использование даты в качестве первичного ключа обыденность. и запросы обычно шарашатся за даты.
Какой ключ в описанной задаче позволит нам использовать эту особенность clickhouse? И если учитывать clickhouse постоянно в фоне перестраивает таблицу какой ключ позволит кликхаусу поменьше времени тратить на сортировку?
По этому мне ваш ответ не понятен, но мне было бы интересно послушать где я косячу в своих рассуждениях.
Вообще то ларавел не спроста выпилил куки из роутов апи. Потому что типа api должно быть RESTful, а следовательно какие к черту сессии?
Однако ж, в самих названиях миддлваре хорошо написано что они делают, и наверное если вы их прочтете, может это как то подскажет вам что надо? Не говоря о том что можно открыть код миддлваре и посмотреть что он делает. Это будет на порядок лучше чем мучать нейронку.
Александр Панков, они придуманы для разных задач. И если бы ваша задача сводилась бы к тому что бы посчитать какое среднее количество отзывов добавляется по дням недели - кликхаус было бы круто. Или вы для разных выборок выбирали бы фиксированное количество колонок. Но сильное подозрение что у вас немножко другие задачи. Или вы думаете что Facebook по каким то философским причинам не может заменить все бд на колоночные?
По разному на диск пишут это как? Насколько я смутно помню что в мускуле что в постгресе по умолчанию системный fsync. А структура хранения разная да, но только это мало что меняет если вам нужно тупо записать 100Тб на диск.
З.Ы. Писал и вспомнил схожий разговор. И бац внезапно мы с вами уже о подобных вещах говорили
Александр Панков,
1. как говорит нам матушка природа скорость чего либо то ни было - конечна. И следовательно даже у NVME будет лимит по чтению и записи. И вот надо сначала смотреть упираетесь ли в этот лимит. И все эти веселья с шардированием возникли ровно потому что какую бы систему хранилища вы не выбрали - то все равно в этот лимит упретесь. Или вы думаете что Facebook по каким то религиозным причинам не может закупить себе NVME - и избавиться от тонны серверов?
2. Ну я честно говоря давно не смотрел чего там по ценам, но сильное подозрение что хранить такие данные как у вас в таком количестве на NVME - такое. Но это тоже можно посчитать - и схожим образом, у меня средняя запись весит 1кб а будет их миллиард. И обойдется это - в столько то.
3. Кликхаус бд которая хорошо работает с выборкой временных данными. А у вас оно тоже есть? Просто запрос выбери мне все отзывы у этого товара - это не работа с временными метками.
4. И еще раз. Какая хрен разница в том кто будет записывать данные на диск? Кликхаус, Постгрес или Мускул? Вы думаете они как то по разному на диск пишут? Или при использовании Clickhouse возникает сотрудник Яндекса с волшебной палочкой и дипломом хогвартса кафедра "изменения законов физики"? Или оверхед у них на сброс одной записи на диск - будет отличаться в 100 раз?
Мне кажется вам сначала стоит посмотреть на другие вещи, нежели Postgres, Kafka, партицирование. Вам стоит понять а какой вообще обьем вы пытаетесь впихнуть. То есть - вот у вас есть отзывы. Предположим в среднем отзыв 1кб, следовательно вам надо впихнуть 1000кб в секунду. Смотрите на диск - какова скорость работы. Ну если 100 кб/с - то собственно какая к черту разница Postgres или MySQL будет пытаться в игольное ушко верблюда пихать, и будет ли ему в этом помогать кафка или раббит, один хрен у вас не влезет? Тут уже смело можно смотреть в сторону шардирования. Если 10000 кб/с то вам вообщем то похрен как мускул будет у 1000 процессов индексы апдейтить, это проблемы MySQL. Нормально будет - ему то чего, если диск спокойно шуршит. А если батчем то даже и хорошо будет.
