Серьезно, я даже не почувствовал подвоха, слишком качественно для WP :)
Клевая затея, жаль способ заработать на ней денег всего один — продать. В идеале гуглу, в реальности какому-нибудь крупному российскому агентству. В остальных сценариях еле хватит на поддержание штанов, да и то не сразу.
Schema-less не подходит, если необходимо любой ценой максимизировать скорость сканирования данных.
Это различие примерно аналогично различию между статической и динамической типизацией.
Мне кажется вы плохо понимаете, как устроен ES. Schema-less отнюдь не значит, что данных хранятся абы как и их структура каждый раз вычисляется заново.
In Elasticsearch, all data in every field is indexed by default. That is, every field has a dedicated inverted index for fast retrieval. And, unlike most other databases, it can use all of those inverted indices in the same query, to return results at breathtaking speed.
У меня нет ни лишнего времени, ни лишней сотни гигабайт на SSD, чтобы провести описанный эксперимент с ES. Буду рад, если вы это сделаете хотя бы с той парой запросов, что я написал. Ставлю 10 к 1, что ES будет быстрее раз в 5.
Но хранить Title inplace в таблице гораздо лучше, чем пытаться сохранить уникальные Title в отдельной таблице и делать сложный JOIN.
Вот тут то и чувствуется вся сила и удобство ES, ибо там этот геморрой вообще не нужен. Сжатие сжатием, но оверхэд в сотни процентов у вас все равно будет. А если вдруг понадобится достать еще одно поле, которое изначально не продублировали — лучше сразу застрелиться.
Не помню, чтобы мы на ты переходили. Предлагаю вам доказать справедливость оценки, сделанной на основании домыслов, и никчемность benchmarks, путем эксперимента.
Конечно можно. В ES нет понятия таблиц, там индексы и документы. Сортировать их можно как угодно, хоть наизнанку — сами лайки по числу постов у автора. В доках как раз пример про посты, не поленитесь. В вашем случае автор и пост будут связаны как parent-child, а лайки можно просто вкладывать в пост. У нас заведения, например, сортируются в т.ч. (но не только, там целая формула) по числу подтвержденных броней за последние 2 месяца, все это внутри одного запроса.
У меня были ngram'ы. Без них все эти 60Гб загрузятся за считанные минуты.
У ES есть nightly benchmarks, на не самых простых данных с гео он загружает по 80к документов в секунду. Это всего 35 минут для данного набора, а скорее всего будет раза в 3 меньше в силу его простой структуры.
Кстати, o6CuFl2Q, сколько ClickHouse требуется времени на загрузку тестового набора?
Вы прямо описываете sweet-spot сценарий для ClickHouse :)
Schema-less была обязательным условием, так что ClickHouse точно нет :)
0.5 GB данных помещаются в page cache и поэтому запросы не должны упираться в дисковую подсистему.
На этом сервере еще всякая фигня крутится, но да, может быть такой эффект. Тем не менее я еще на старых версиях ES экспериментировал с индексами размером в десятки GB и куда более простыми запросами (полнотекстовый поиск + 2-3 параметра) — ответ всегда укладывался в десятки миллисекунд.
Предположительно, будет одна «big flat table» с исходными событиями, и один или несколько запросов со всеми нужными агрегатными функциями.
Событие (event) относится к input'у, тот в свою очередь принадлежит form, которая относится к pageview. На один pageview, естественно, может быть несколько форм, сотни инпутов и десятки тысяч событий. Агрегация идет на всех уровнях — и по событиям, и по инпутам/их типам, и по формам, и по pageview. big flat точно не вариант, было бы огромное дублирование.
В случае с ES это один schema-less документ — pageview, в котором все вложено, и делать с ним можно все, что угодно — например посчитать общее число submit'ов отдельно для каждого встречающегося класса формы для pageview с OS = Windows и форм с action = /book, сортировка по количеству pageview для каждого класса формы. Занимает это строчек 20 и считается попутно со всем остальным. Попробуйте здесь такой же запрос для ClickHouse нарисовать ;)
Про 3-4 часа на загрузку таких данных это вы загнули. Еще года 3 назад в моих экспериментах с ES 0.9x пара гигабайт XML-фидов превращалась в json и заливалась на одну ноду/индекс минут за 30ть, с сервером на HDD. В индексе при этом был полнотекстовый поиск с ngram'ами, вес индекса на выходе за 15GB. Сейчас все еще быстрее, а простые данные в простой индекс вообще грузятся близко к скорости самого SSD.
Без проблем, например вот это отдаст сразу из каких городов отправляется больше рейсов и распределение времени задержки прилёта, по авиакомпаниям в одном запросе, да еще и наверняка быстрее:
Это 2 простейших агрегации (terms и квантили), все остальное тоже легко выполнимо — в ES три десятка разных агрегаций, которые спокойно накладываются, вкладываются и поворачиваются как угодно.
Более того, ES умеет еще и сам находить "выделяющиеся из общей массы" значения, например по каждой авиакомпании подсказать город, из которого она летает заметно чаще остальных авиакомпаний. Это настолько сложно, что надо всего-лишь добавить в последний aggs перед/после avg_delays это:
Я уж не говорю про невероятно удобную работу с датами и геолокацией — хочешь тебе агрегации и вычисления, хочешь — сортировка с экспоненциальным убыванием веса от расстояния, при этом, например, ближе 300м вес одинаковый, дальше 3км вообще всем ноль. Берите дистрибутив и пробуйте, документация там более чем понятная. ES очень активно используют Github, Foursquare, Twitter, Netflix и многие другие, вплоть до Cisco с Microsoft. Свой велосипед можете выбросить.
P.S. Если что — я как раз недавно написал систему аналитики форм, использующую ES и одним запросом считающую 2 десятка показателей вроде квантилей среднего времени, потраченного на каждое поле, % юзеров, взаимодействовавших/менявших это поле, средней длины вводимого в поле текста и т.д. Все это с группировкой/фильтрацией по чему угодно — хоть по ОС или урлу, хоть по css-классу формы (и дате, естественно). В базе сырые данные — события (click, focusin, change и т.д.) и время, десятки миллионов записей и 0.5GB данных для одного небольшого сайта, на котором все это обкатывается. Уровень вложенности агрегаций уходит за 10, все крутится на маленьком запасном сервере с HDD(!) и отдает все два десятка показателей с двойной группировкой и любой фильтрацией за 1 секунду уже в виде HTML. Если сильно интересно — могу дать посмотреть. С вашей штукой это превратилось бы в 30 отдельных запросов с кучей подзапросов и структуру данных из 3-4х таблиц, которые надо постоянно join'ить. Про скорость даже боюсь думать :)
Отнюдь, у Elasticsearch сейчас отличные возможности по фильтрации, агрегации и вообще работе с большими объёмами постоянно поступающих данных. Скорость, надёжность и удобство на высоте. Для любой аналитики — самое то, у них на сайте можно посмотреть, сколько огромных систем на нем построено. Полнотекстовый поиск там лишь одна из сотен функций.
А зачем он тогда нужен? Надежность? История подсказывает, что нет. Анонимность? Итак хватает анонимных при умелом использовании финансовых инструментов. Да и кому это нужно — торговцам наркотиками/оружием и IT-параноикам?
Все это больше похоже на забаву — толпа айтишников решила поиграть в центробанк. Причем за короткий срок уже успела случиться пара дефолтов.
Попробовал посчитать профит от Bitcoin. Пара уже имеющихся у меня серверов принесет не больше, чем 5-10$ в месяц (о, да я богат!). Чтобы зарабатывать хотя бы 100$ в месяц, надо накупить железа на 10 000$. Про суммы от 1 000$ промолчу — проще положить деньги на депозит в банк. Кто-нибудь объяснит мне, в чем смысл?
Не нравятся развлекательные статьи — так не читайте их. Не согласны с мнением автора — корректно приведите другое. Это, как мне кажется, элементарная вежливость и здравый смысл.
Мне тоже не все статьи на Хабре нравятся и иногда автор идиот, но я в таких случаях не буду тратить время и просто пройду мимо. Когда вместо этого люди начинают брызгать слюной, срать в карму и писать огромные топики в ответ — это уже признак психического заболевания.
Здорово. Мой пост для одного типа людей, этот — для другого. Выводы получились одни и те же («постараюсь в ответ рассказать» — что в итоге рассказал то? что ничего точно не известно? спасибо, кэп!). Почему на Хабре у отдельных личностей неистерпимый зуд доказать, что я не прав — загадка.
Да, Ваш пост в разы лучше. 99% в нем вообще ничего не поймет и даже читать не станет, но это не главное. Главное, что Вы правы.
И еще больше радует Ваш вывод, что на самом деле точно не известно, что там происходит со временем. Именно об этом и был мой пост, можно было и не расшибаться в лепешку, рисуя сложные дифференциалы.
Вы, видимо, не видите разницы между земными расстояними, где погрешность в 0,00001% ничего не значит, и космическими, где такая погрешность приводит к исчезновению пары галактик?
Серьезно, я даже не почувствовал подвоха, слишком качественно для WP :)
Клевая затея, жаль способ заработать на ней денег всего один — продать. В идеале гуглу, в реальности какому-нибудь крупному российскому агентству. В остальных сценариях еле хватит на поддержание штанов, да и то не сразу.
Отличный лэндинг! Кто рисовал?
Нам, как бывшему работодателю, уже дали пожизненный доступ? ;))
Взрослое быдло — все равно быдло.
Мне кажется вы плохо понимаете, как устроен ES. Schema-less отнюдь не значит, что данных хранятся абы как и их структура каждый раз вычисляется заново.
У меня нет ни лишнего времени, ни лишней сотни гигабайт на SSD, чтобы провести описанный эксперимент с ES. Буду рад, если вы это сделаете хотя бы с той парой запросов, что я написал. Ставлю 10 к 1, что ES будет быстрее раз в 5.
Вот тут то и чувствуется вся сила и удобство ES, ибо там этот геморрой вообще не нужен. Сжатие сжатием, но оверхэд в сотни процентов у вас все равно будет. А если вдруг понадобится достать еще одно поле, которое изначально не продублировали — лучше сразу застрелиться.
Не помню, чтобы мы на ты переходили. Предлагаю вам доказать справедливость оценки, сделанной на основании домыслов, и никчемность benchmarks, путем эксперимента.
Конечно можно. В ES нет понятия таблиц, там индексы и документы. Сортировать их можно как угодно, хоть наизнанку — сами лайки по числу постов у автора. В доках как раз пример про посты, не поленитесь. В вашем случае автор и пост будут связаны как parent-child, а лайки можно просто вкладывать в пост. У нас заведения, например, сортируются в т.ч. (но не только, там целая формула) по числу подтвержденных броней за последние 2 месяца, все это внутри одного запроса.
У меня были ngram'ы. Без них все эти 60Гб загрузятся за считанные минуты.
У ES есть nightly benchmarks, на не самых простых данных с гео он загружает по 80к документов в секунду. Это всего 35 минут для данного набора, а скорее всего будет раза в 3 меньше в силу его простой структуры.
Кстати, o6CuFl2Q, сколько ClickHouse требуется времени на загрузку тестового набора?
Schema-less была обязательным условием, так что ClickHouse точно нет :)
На этом сервере еще всякая фигня крутится, но да, может быть такой эффект. Тем не менее я еще на старых версиях ES экспериментировал с индексами размером в десятки GB и куда более простыми запросами (полнотекстовый поиск + 2-3 параметра) — ответ всегда укладывался в десятки миллисекунд.
Событие (event) относится к input'у, тот в свою очередь принадлежит form, которая относится к pageview. На один pageview, естественно, может быть несколько форм, сотни инпутов и десятки тысяч событий. Агрегация идет на всех уровнях — и по событиям, и по инпутам/их типам, и по формам, и по pageview. big flat точно не вариант, было бы огромное дублирование.
В случае с ES это один schema-less документ — pageview, в котором все вложено, и делать с ним можно все, что угодно — например посчитать общее число submit'ов отдельно для каждого встречающегося класса формы для pageview с OS = Windows и форм с action = /book, сортировка по количеству pageview для каждого класса формы. Занимает это строчек 20 и считается попутно со всем остальным. Попробуйте здесь такой же запрос для ClickHouse нарисовать ;)
Про 3-4 часа на загрузку таких данных это вы загнули. Еще года 3 назад в моих экспериментах с ES 0.9x пара гигабайт XML-фидов превращалась в json и заливалась на одну ноду/индекс минут за 30ть, с сервером на HDD. В индексе при этом был полнотекстовый поиск с ngram'ами, вес индекса на выходе за 15GB. Сейчас все еще быстрее, а простые данные в простой индекс вообще грузятся близко к скорости самого SSD.
Без проблем, например вот это отдаст сразу из каких городов отправляется больше рейсов и распределение времени задержки прилёта, по авиакомпаниям в одном запросе, да еще и наверняка быстрее:
Это 2 простейших агрегации (terms и квантили), все остальное тоже легко выполнимо — в ES три десятка разных агрегаций, которые спокойно накладываются, вкладываются и поворачиваются как угодно.
Более того, ES умеет еще и сам находить "выделяющиеся из общей массы" значения, например по каждой авиакомпании подсказать город, из которого она летает заметно чаще остальных авиакомпаний. Это настолько сложно, что надо всего-лишь добавить в последний
aggsперед/послеavg_delaysэто:Я уж не говорю про невероятно удобную работу с датами и геолокацией — хочешь тебе агрегации и вычисления, хочешь — сортировка с экспоненциальным убыванием веса от расстояния, при этом, например, ближе 300м вес одинаковый, дальше 3км вообще всем ноль. Берите дистрибутив и пробуйте, документация там более чем понятная. ES очень активно используют Github, Foursquare, Twitter, Netflix и многие другие, вплоть до Cisco с Microsoft. Свой велосипед можете выбросить.
P.S. Если что — я как раз недавно написал систему аналитики форм, использующую ES и одним запросом считающую 2 десятка показателей вроде квантилей среднего времени, потраченного на каждое поле, % юзеров, взаимодействовавших/менявших это поле, средней длины вводимого в поле текста и т.д. Все это с группировкой/фильтрацией по чему угодно — хоть по ОС или урлу, хоть по css-классу формы (и дате, естественно). В базе сырые данные — события (click, focusin, change и т.д.) и время, десятки миллионов записей и 0.5GB данных для одного небольшого сайта, на котором все это обкатывается. Уровень вложенности агрегаций уходит за 10, все крутится на маленьком запасном сервере с HDD(!) и отдает все два десятка показателей с двойной группировкой и любой фильтрацией за 1 секунду уже в виде HTML. Если сильно интересно — могу дать посмотреть. С вашей штукой это превратилось бы в 30 отдельных запросов с кучей подзапросов и структуру данных из 3-4х таблиц, которые надо постоянно join'ить. Про скорость даже боюсь думать :)
Все это больше похоже на забаву — толпа айтишников решила поиграть в центробанк. Причем за короткий срок уже успела случиться пара дефолтов.
Мне тоже не все статьи на Хабре нравятся и иногда автор идиот, но я в таких случаях не буду тратить время и просто пройду мимо. Когда вместо этого люди начинают брызгать слюной, срать в карму и писать огромные топики в ответ — это уже признак психического заболевания.
И еще больше радует Ваш вывод, что на самом деле точно не известно, что там происходит со временем. Именно об этом и был мой пост, можно было и не расшибаться в лепешку, рисуя сложные дифференциалы.