SC
я читал про Neo4j - оно действительно хорошо работает с связями типа "поиска друзей друзей друзей"
Size: a a a
2021 January 01
IZ
тоесть простые джоины - это например, запрос всех постов пользователей, где нужно всего один джоин?
Если бы что-то можно было бы за O(1) искать...
A
тоесть простые джоины - это например, запрос всех постов пользователей, где нужно всего один джоин?
Это простой джойн вполне тянет.
С иерархическими ответами в форумах посложней, та же Closure table в реляции - структура допоонительная, а значит должна при сохранении меняться в той же транзакции, чтобы быть актуалтной, плюс места жрет больше чистых данных. Зато на поиске сообщений форума с учетом кглубины летает.
А найти связь пользователя с другими вплоть до глубины пятого контакта - это уже графовые структуры.
С иерархическими ответами в форумах посложней, та же Closure table в реляции - структура допоонительная, а значит должна при сохранении меняться в той же транзакции, чтобы быть актуалтной, плюс места жрет больше чистых данных. Зато на поиске сообщений форума с учетом кглубины летает.
А найти связь пользователя с другими вплоть до глубины пятого контакта - это уже графовые структуры.
IZ
Anton
Это простой джойн вполне тянет.
С иерархическими ответами в форумах посложней, та же Closure table в реляции - структура допоонительная, а значит должна при сохранении меняться в той же транзакции, чтобы быть актуалтной, плюс места жрет больше чистых данных. Зато на поиске сообщений форума с учетом кглубины летает.
А найти связь пользователя с другими вплоть до глубины пятого контакта - это уже графовые структуры.
С иерархическими ответами в форумах посложней, та же Closure table в реляции - структура допоонительная, а значит должна при сохранении меняться в той же транзакции, чтобы быть актуалтной, плюс места жрет больше чистых данных. Зато на поиске сообщений форума с учетом кглубины летает.
А найти связь пользователя с другими вплоть до глубины пятого контакта - это уже графовые структуры.
А что значит простой join?
Что, есть непростые?
Что, есть непростые?
SC
Anton
Социалку вроде лучше всего графовая структура вывозит, т.е. можно Neo4j поколупать - графовые БД как раз заточены чтобы двигаться по графам связей пользователей без джойнов O(log n), а индексным доступом O(1), но можно наклететь на обратных эфыект - когда понадрбятся аростые джойны их не будет, либо будут очень тормозить.
А кассандра, насколько я понимаю, лучше всего в OLAP - когда нужно тьму денормальзованных данных напихать в одну таблицу с почти неограниченным количеством столбцов и быстро O(1) искать по комбинацим значенияй этих столбцов. По сравнению с апелляционной это "быстро" можно хоть как-то нащупать от 10кк записей.
А кассандра, насколько я понимаю, лучше всего в OLAP - когда нужно тьму денормальзованных данных напихать в одну таблицу с почти неограниченным количеством столбцов и быстро O(1) искать по комбинацим значенияй этих столбцов. По сравнению с апелляционной это "быстро" можно хоть как-то нащупать от 10кк записей.
"По сравнению с реляционной это "быстро" можно хоть как-то нащупать от 10кк записей." - да, а что с ними потом делать с этими записями, их же не посортировать ни отфильтровать, куда их)
A
Если бы что-то можно было бы за O(1) искать...
Условно O(1), не пыли. На больших обьемах в коастерах и сложных стпуктурах конечно не будет такого.
A
А что значит простой join?
Что, есть непростые?
Что, есть непростые?
Есть непростые, которые нереляционные и не джойны)
IZ
Anton
Условно O(1), не пыли. На больших обьемах в коастерах и сложных стпуктурах конечно не будет такого.
Я не понял ни слова...
Но ладно, не важно
Но ладно, не важно
SC
"По сравнению с реляционной это "быстро" можно хоть как-то нащупать от 10кк записей." - да, а что с ними потом делать с этими записями, их же не посортировать ни отфильтровать, куда их)
вторичные индексы - не рекомендуют, условия ставить только поставив все условия к ключам, materialized views - не рекомендуют), удаление - не удаление на самом деле и т.д,)
A
"По сравнению с реляционной это "быстро" можно хоть как-то нащупать от 10кк записей." - да, а что с ними потом делать с этими записями, их же не посортировать ни отфильтровать, куда их)
Посчитать количество товаров по критериям
IZ
Anton
Есть непростые, которые нереляционные и не джойны)
Главное, чтобы вы с Вячеславом понимали друг друга...
SC
Anton
Посчитать количество товаров по критериям
да, хорошо, а как допустим отсортировать по возрастанию, чтобы я видел товары допустим, которых наибольшее количество
A
Главное, чтобы вы с Вячеславом понимали друг друга...
Скорректируй, где не прав, чего сразу бред то..
SC
сортировки ведь тоже по ключам только) не делать же таблицу с ключом "количество" тем более каунтеры нельзя в качестве ключа использовать
A
да, хорошо, а как допустим отсортировать по возрастанию, чтобы я видел товары допустим, которых наибольшее количество
У тебя кассандра тупит на сортировке?
SC
Anton
У тебя кассандра тупит на сортировке?
нет, просто я не понимаю как там нормально сортировать данные, чтобы я получал сразу отпагинированные отсортированные данные
SC
думаю она для этого не подходит
SC
PRIMARY KEY (post_id, amount_of_likes) ... ORDER BY amount_of_likes DESC - это конечно заработает
A
думаю она для этого не подходит
По-моему и реляционка для такого не подходит))
По пейджингу с фильтрами и сортировкой надо уже под задачу оптимизировать
По пейджингу с фильтрами и сортировкой надо уже под задачу оптимизировать
SC
Anton
По-моему и реляционка для такого не подходит))
По пейджингу с фильтрами и сортировкой надо уже под задачу оптимизировать
По пейджингу с фильтрами и сортировкой надо уже под задачу оптимизировать
ок, задача: вытянуть посты, отсортированные по популярности (лайкам) и отфильтрованные, допустим чтобы показывало только рецепты с мультиварками ))