Здравствуйте, Anton Batenev, Вы писали:
AB>На дисках в FIFO режиме хранятся только оперативные данные. Попробуй прикинуть сколько камер в одном магазине и сколько занимает суточный стрим одной камеры. Конечно же стримы нужно обрабатывать и в базу кладется уже "выжимка".
Сколько? По моим оценкам 150Г с камеры в месяц максимум, это 1 террабайтник на 6-7 камер на месяц, если писать непрерывно и круглосуточно, а не только по движению. В магазинах часто даже 720р нет, часто Ч/Б, 15fps, и все это неплохо сжато, можешь сам прикинуть.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, IB, Вы писали:
IB>·>Не понял я... кто чего не говорит? Явно же говорилось, какие варианты они не стали брать. Oracle RAC, например. IB>Ну вот тот факт, что они не стали брать Оракл, ничего не говорит про Оракл. Их кейс говорит только про тот вариант который они взяли, а не про тот который не взяли.
А какой они могли взять, но не взяли и почему не взяли?
IB>·>Какую? Название в студию. IB>Могну, если мне память не изменяет.
Не слышал эту историю. Рассказывай.
IB>·>Сделаешь, но не в sql. IB>Это в ручную что ли? Ну вот "сами топите урановые ломы в ртути" (с) Зачем связываться с кв, если мне нужны джойны и мускул это сделает быстрее и проще?
В том то и дело, что иногда сделает, а иногда не сделает. Ломы в ртути топил, например, facebook, когда насиловал mysql, но в конце концов у них таки случился сабж.
IB>·>Верно, факт в том, что FTS никто серьёзно и не использует, ибо сделан он чисто для галочки. IB>Факт в том, что FTS используют в тех проектах где его достаточно, где не достаточно — не используют.
И где его достаточно? Другими словами, назови пару известных проектов, которые на нём сидят.
IB>Второй факт, как уже неоднократно говорилось, FTS в принципе не сиквельная задача,
Верно. Вот и объясни зачем оно в mssql?
IB>равно как и не NoSQL-ная, и как правило решается отдельным индексом, коим обычно и является люцена или эластик в зависимости от задачи.
Видимо что-то не так в терминологии. Что по-твоему nosql-ная задача? Эластик, по-моему, обычная типичная nosql база данных.
IB>Какие тут претензии к реляционкам я продолжаю не понимать.
Пытаюсь выяснить что скрывается за "на сегодня все взрослые РСУБД обзавелись полезными фичами NoSQL". Вот интересно что собственно это значит.
IB>>>Для хранения используют. А для чего вы хотите SQL использовать мне не ведомо. IB>·> Тонкий намёк: Structured QUERY Language. IB>На что намек? Выражайтесь яснее, а то я точно так же могу выделить слово structured с глубокомысленным видом.
Что sql это не про хранение данных (данные вообще-то и в файлах замечательно хранятся или вообще на магнитных лентах), а про запросы к данным.
IB>>>Понятия не имею что такое LSE и при чем тут MSSQL, мы же здесь про NoSQL говорим. IB>·>http://lmgtfy.com/?q=lse+mssql — это про доступность в mssql. IB>Аргумент из серии "а у вас негов линчуют". К тому же мимо — "The London Stock Exchange claimed that the TradElect software was not to blame, instead blaming an unspecified fault with network software" (с)
Опять ведёшься на маркетинг. Логично, что они говорят такое, прикрывая друг друга. Но не важно что там говорили — надо смотреть на результат и что они делали потом: "TradElect had been completely replaced with Millennium Exchange".
IB>Причем тут реляционка? Амазон неделю назад тоже лежал по причине "unspecified fault with network software", значит как уже неоднократно утверждалось, никакой надежды на ваш NoSQL нет ))
Опять же надо смотреть на то что они делают в итоге.
IB>·>Всё полезное должны были втащить. Вот цитата: "на сегодня все взрослые РСУБД обзавелись полезными фичами NoSQL". IB>Не понимаю как это относится к этой части разговора, поскольку как я и писал, в NoSQL этого тоже нет, поэтому и втаскивать нечего. IB>Но тем не менее хочу обратить внимание в приведенной же вами цитате на слово "полезными". Полезными для хранения данных. Ни кэш уровня приложения, ни FTS к таким задачам не относятся. Вот работа с JSON относится, ее и втащили в полный рост.
Не понял логику. Хранить json можно в текстовом блобе — и это было всегда. А втащили они именно индексацию и поиск по этим самым json-блобам. Почему поиск по тексту менее полезен поиска по json — мне непонятно. Или логика такова, что называем полезным только то, что втащили и что хоть как-то приемлимо работает?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>·>Может быть вопрос терминологии... По мне ES вполне таки nosql, хранилище неструктурированных json документов, индексация, поиск и т.д. Разве нет? НС>Нет. ES в контексте SO вообще не хранилище, и используется по своему изначальному назначению, в качестве сервиса полнотекстового поиска.
"A NoSQL database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases." А конкретнее ES это https://en.wikipedia.org/wiki/Document-oriented_database
НС>Вот ELK, тут да, можно, при желании, как rich storage трактовать.
ELK вообще интеграция ES с парсером логов и визуализатором. От того что к индексированному nosql storage добавили визуализатор он richer не станет. Или у тебя какая-то особая терминология.
НС>>>ES вовсе не обязан хранить данные в NoSQL, кстати. НС>·>Не знал. А подробнее? НС>https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-store.html
"Configure the type of filesystem used to access shard data" — т.е. выбор того, какое файловое API используетя для доступа к файловой системе — raf, nio или mmap. А ES в итоге хранит свои данные в файлах, как и рсубд. Причём тут nosql-ность?
НС>·>"все взрослые РСУБД обзавелись полезными фичами NoSQL". НС>Это не он утверждал,
А кто же по-твоему? У меня все ходы записаны
.
НС>и речь шла не про fts, который и фичей nosql вряд ли можно назвать.
Про fts он в другом сообщени упоминал.
Давай теперь выясним что называть фичей nosql? И особенно интересно что называть "полезной фичей".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>>C фига ли? OLTP весь был и остаётся на RDBMS. C>>Уже нет. Amazon — небольшая компания, которая продаёт в год товаров на сумму ВВП небольшой страны. RDBMS запрещены везде, где нужно OLTP. На использование RDBMS нужно получать разрешение на уровне VP. НС>И чего произойдет если изредка Амазончик сбойнет? Да ничего. Особенно если убрать самые неприятные варианты типа продаж несуществующего товара. Ну нажмет юзверь еще разок, все уже к глюкам современного веба привыкли.
Миллионные потери от простоя.
НС>А что произойдет если сбойнет банк? ЖОПА.
Они постоянно сбоят. Ничего не произойдёт. В худщем случае — извинятся перед клиентами.
C>>Гугл — примерно аналогично. НС>Еще смешнее.
Прям обхохочешься.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, gandjustas, Вы писали:
Ops>>>·>Т.е. получается, что элементарная функциональность "получить по ID текст сообщения — оно и дёргает SQL (и то не всегда , а только если в redis не оказалось случайно), а нетривиальные вещи уже требуют чего-то более хитрого. Ops>>>Конечно требуют. Вопрос — как часто, и многим ли это нужно? G>·>Похоже что нужно. Иначе зачем бы SO стал заморачиваться со всякими тег-енджинами и эластиками? Ведь всё это можно и во всемогущем MS SQL реализовать. G>Ты бы читал блоги, на которые ссылаешься. G>1) tag engine был просто частью приложения. Но вынесли в отдельный сервис на C++, потому что не смогли написать tag engine на .NET, чтобы он не тормозил.
Я-то читал: "the tag engine also continually index items in Elasticsearch".
G>2) elastic search стоит по причине того, что стоимость процессорных ядер в MS SQL высокая.
Главное потому что "FTS убог".
G>Так что все можно в MS SQL, но некоторые вещи выгоднее отдельно.
Ага-ага. Тебе тут уже ответили: "Человек просто никогда с FTS на реальном проекте не сталкивался."
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Cyberax, Вы писали:
C>Ну так он победил РСУБД и стал обычным инструментом.
Весь топик не асилил, но закат NoSQL и появление NewSQL уже обсудили?
Здравствуй.те, ·, Вы писали:
НС>>Вот ELK, тут да, можно, при желании, как rich storage трактовать. ·>ELK вообще интеграция ES с парсером логов и визуализатором.
Ты не с той стороны смотришь. Дело не в том как устроено, а в том для чего используется.
·>"Configure the type of filesystem used to access shard data" — т.е. выбор того, какое файловое API используетя для доступа к файловой системе — raf, nio или mmap. А ES в итоге хранит свои данные в файлах, как и рсубд. Причём тут nosql-ность?
Вот именно
·>Давай теперь выясним что называть фичей nosql? И особенно интересно что называть "полезной фичей".
Здравствуйте, Ops, Вы писали:
Ops>·>Эээ... Ну допустим 3.1415926% пользуются. И что? Ops>И значит вклад этой фигни в работу сервиса едва заметен, и без нее сервис ухудшится незначительно
И к чему ты это ведёшь? Что в SO работают идиоты, которые парятся со всякой никому не нужной фигнёй?
Притом основываешь своё "незначительно" лишь на основании моих предположений для чего они могут использовать ES.
Кстати, tag engine тоже использует ES, судя по той статье. Я могу ещё накидать предположений для чего они его применяют — например для поиска и сопоставления резюме профилям пользователей (собственно этим они монетизируют свой бизнес).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Вот ELK, тут да, можно, при желании, как rich storage трактовать. НС>·>ELK вообще интеграция ES с парсером логов и визуализатором. НС>Ты не с той стороны смотришь. Дело не в том как устроено, а в том для чего используется.
Ещё раз, ELK это готовый продукт. А ES это nosql хранилище документов.
НС>·>"Configure the type of filesystem used to access shard data" — т.е. выбор того, какое файловое API используетя для доступа к файловой системе — raf, nio или mmap. А ES в итоге хранит свои данные в файлах, как и рсубд. Причём тут nosql-ность? НС>Вот именно
Не понял. А MSSQL тоже хранит данные в файлах. Он значит не является SQL, т.к. к нему не прикручена kibana?
НС>·>Давай теперь выясним что называть фичей nosql? И особенно интересно что называть "полезной фичей". НС>Спор о терминах? Без меня.
Ты только что заявил, что ES не является nosql, потому что в нём нет визуализатора. Кхм. Или я вообще перестал тебя понимать.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Gt_>>в эпоху бигдаты весьма глупое у тебя занятие. чуть подрастет нагрузка и в первом случае у тебя встанет колом не умеющий масштабироваться из-за сборки мусора постгре, хранящий мусор прямо в датафайлах. убер это проходил. GIV>Нормально там все с бигдатой, поверь на слово, проверено эксплуатацией у крупных провайдеров типа Билайна.
да ладно. к билингу постгрес точно не подпустят, а аналитика у телекома хадуп стандарт. для аналитики там гринпум, напоминающий постгре, такой же платный как и оракл.
Gt_>>во втором случае гарантированно сдохнет бизнес от счетов. GIV>Я не считал, надеюсь специально обученные люди провели все расчеты GIV>Начальство делало доклад на гугл некст, народ был excited
да. типично для специально обученных. мы вот в частное облако мигрируем после таких же подсчетов. теперь начальство excited — поднять бэкап с ленты 600 евро ... причем то что провайдер не смог найти нужную ленту отдельная хохма. как я понимаю мы оплатим и попытку бэкапа и их время затраченное на анализ их проблем.
Здравствуйте, ·, Вы писали:
·>И к чему ты это ведёшь? Что в SO работают идиоты, которые парятся со всякой никому не нужной фигнёй?
А до продакшна неизвестно, насколько она нужная. ·>Притом основываешь своё "незначительно" лишь на основании моих предположений для чего они могут использовать ES.
Ну так лучше данных ты не нашел ·>Кстати, tag engine тоже использует ES, судя по той статье. Я могу ещё накидать предположений для чего они его применяют — например для поиска и сопоставления резюме профилям пользователей (собственно этим они монетизируют свой бизнес).
Только это все никакой не хайлоад, и либо может спокойно крутиться в фоне в свободное время, либо, как эти резюме, испытывает смешные нагрузки.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, ·, Вы писали:
НС>>И чего произойдет если изредка Амазончик сбойнет? Да ничего. Особенно если убрать самые неприятные варианты типа продаж несуществующего товара. Ну нажмет юзверь еще разок, все уже к глюкам современного веба привыкли. ·>Миллионные потери от простоя.
Какого простоя? Просто юзверь еще разок нажмет на кнопу и все сработает.
НС>>А что произойдет если сбойнет банк? ЖОПА. ·>Они постоянно сбоят. Ничего не произойдёт. В худщем случае — извинятся перед клиентами.
Здравствуйте, ·, Вы писали:
IB>>Второй факт, как уже неоднократно говорилось, FTS в принципе не сиквельная задача, ·>Верно. Вот и объясни зачем оно в mssql?
Это простой вопрос. Попросил какой то очень крупный заказчик. Такое с производителяи корпоративного софта случается.
Здравствуйте, ·, Вы писали:
НС>>Ты не с той стороны смотришь. Дело не в том как устроено, а в том для чего используется. ·>Ещё раз, ELK это готовый продукт. А ES это nosql хранилище документов.
Elasticsearch is a distributed, RESTful search and analytics engine capable of solving a growing number of use cases.
С сайта авторов.
НС>>·>Давай теперь выясним что называть фичей nosql? И особенно интересно что называть "полезной фичей". НС>>Спор о терминах? Без меня. ·>Ты только что заявил, что ES не является nosql, потому что в нём нет визуализатора.
Здравствуйте, Ночной Смотрящий, Вы писали:
IB>>>Второй факт, как уже неоднократно говорилось, FTS в принципе не сиквельная задача, НС>·>Верно. Вот и объясни зачем оно в mssql?
НС>Это простой вопрос. Попросил какой то очень крупный заказчик. Такое с производителяи корпоративного софта случается.
Как щас не знаю, но, если память не изменяет, раньше fts даже не ставился по умолчанию при инсталяции sql server. Т.е. по сути fts — дополнительный сервис рядом с движком sql'я
Здравствуйте, Ops, Вы писали:
Ops>·>И к чему ты это ведёшь? Что в SO работают идиоты, которые парятся со всякой никому не нужной фигнёй? Ops>А до продакшна неизвестно, насколько она нужная.
И что? А после продакшна что мешает выкинуть?
Ops>·>Притом основываешь своё "незначительно" лишь на основании моих предположений для чего они могут использовать ES. Ops>Ну так лучше данных ты не нашел
Косвенно можно сделать выводы. Тут две альтернативы — либо им ES нужен, либо они идиоты и им делать больше нефиг. Я склоняюсь к первому.
Ops>·>Кстати, tag engine тоже использует ES, судя по той статье. Я могу ещё накидать предположений для чего они его применяют — например для поиска и сопоставления резюме профилям пользователей (собственно этим они монетизируют свой бизнес). Ops>Только это все никакой не хайлоад, и либо может спокойно крутиться в фоне в свободное время, либо, как эти резюме, испытывает смешные нагрузки.
Он настолько не хайлоад, что под него нужны были дополнительные линцензии для mssql либо ES.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>А какой они могли взять, но не взяли и почему не взяли?
Понятия не имею, я там свечку не держал. Зная как принимаются решения в энтерпрайзе, примерно могу себе представить, но это не имеет отношения к делу.
·>Не слышал эту историю. Рассказывай.
Ну собственно рассказал уже. Долго возились с монгой, было быстро но бестолково. Взяли мускул, доточили хранилище на предмет лишних записей на диск, стало удобнее и в три раза быстрее.
·>В том то и дело, что иногда сделает, а иногда не сделает. Ломы в ртути топил, например, facebook, когда насиловал mysql, но в конце концов у них таки случился сабж.
Что у них случилось, кэш прикрутили? Если я правильно помню, основное хранилище у них все еще на мускуле.
·>И где его достаточно? Другими словами, назови пару известных проектов, которые на нём сидят.
Много где. Подозреваю, что проектов где его достаточно, сильно больше, чем где недостаточно, даже если известных проектов на нем вообще нет.
·>Верно. Вот и объясни зачем оно в mssql?
Что бы было что использовать в тех проектах, где его хватает. Как мы выяснили, софт для атомных реакторов пишут далеко не все, но им все равно нужен простой функционал поиска из коробки.
·>Видимо что-то не так в терминологии. Что по-твоему nosql-ная задача? Эластик, по-моему, обычная типичная nosql база данных.
Ну, по вашему, может быть, но даже сами авторы эластика не уверены считать ли его NoSQL. "it neither makes sense to precisely define NoSQL, nor to simply say that Elasticsearch is a "document store"-type NoSQL-database." (c)
По факту это поисковый полнотекстовый индекс в виде сервиса для различных источников данных, как реляционных, так и не очень.
IB>>Какие тут претензии к реляционкам я продолжаю не понимать. ·>Пытаюсь выяснить что скрывается за "на сегодня все взрослые РСУБД обзавелись полезными фичами NoSQL". Вот интересно что собственно это значит.
Добавили полезные для надежного хранения и работы с данными фичи, типа работы с JSON, поддержки питона и R для ML, и т. д.
·>Что sql это не про хранение данных (данные вообще-то и в файлах замечательно хранятся или вообще на магнитных лентах), а про запросы к данным.
Конкретно язык sql — действительно для запросов, но вас не смущает, что большинство noSQL поддерживают SQL в полный рост?
Однако здесь мы вроде как разговариваем не о языке SQL, а под SQL понимали реляционные хранилища, если явно не сказано обратного, так что не надо на ходу переобуваться ))
·>Но не важно что там говорили — надо смотреть на результат и что они делали потом: "TradElect had been completely replaced with Millennium Exchange".
Ага, 4 года спустя, когда туда пришел новый директор, которому надо было показать кто тут хозяин. Конечно — MSSQL виноват ))
·>Не понял логику. Хранить json можно в текстовом блобе — и это было всегда. А втащили они именно индексацию и поиск по этим самым json-блобам. Почему поиск по тексту менее полезен поиска по json — мне непонятно. Или логика такова, что называем полезным только то, что втащили и что хоть как-то приемлимо работает?
Логика такова, что в JSON хранятся структурированные данные. И в некоторых сценариях удобно хранить их как есть, не разбивая по таблицам. Поэтому возможность индексировать их и строить по ним запросы выглядит логичным дополнением к функционалу хранилища.
В случае же FTS, данные мало того что не структурированы, так еще и поиск зачастую нужен не только по тем данным, что хранятся в базе. Поэтому вполне разумно иметь в хранилище только базовый функционал, а если нужно взрослое решение, использовать внешний сервис индексирования.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>И чего произойдет если изредка Амазончик сбойнет? Да ничего. Особенно если убрать самые неприятные варианты типа продаж несуществующего товара. Ну нажмет юзверь еще разок, все уже к глюкам современного веба привыкли. НС>·>Миллионные потери от простоя. НС>Какого простоя? Просто юзверь еще разок нажмет на кнопу и все сработает.
Не знаю про какую кнопку ты говоришь. Но временный обрыв связи это не сбой, а специфика функционирования Интернета.
У них есть важные дни, типа чёрной пятницы и если оно не выдерживает нагрузку — ой — поезд ушел.
НС>>>А что произойдет если сбойнет банк? ЖОПА. НС>·>Они постоянно сбоят. Ничего не произойдёт. В худщем случае — извинятся перед клиентами. НС>А, ну ну.
Так следи за новостями. Постоянно что-то сыпется в it банков. Вот, вот из того что я помню навскидку из свежего.
Видишь ли, банки это финансовые организации и их бизнес основан на надёжности их юристов, финансистов, аудита, и прочей бюрократии, для них IT это просто второстепенная часть организации. Проблемы IT обычно влияют на них так же как проблемы с водопроводом. А вот для IT-компаний типа гугла/амазона — бизнес и прибыли напрямую зависят от надёжности IT.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>И что? А после продакшна что мешает выкинуть?
Зачем выкинуть? Полезная фича, пусть на поверку и слабо востребованная
·>Он настолько не хайлоад, что под него нужны были дополнительные линцензии для mssql либо ES.
Так выходит, ES им нужен только из-за экономии денег на лицензиях mssql?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Ты не с той стороны смотришь. Дело не в том как устроено, а в том для чего используется. НС>·>Ещё раз, ELK это готовый продукт. А ES это nosql хранилище документов. НС>
НС>Elasticsearch is a distributed, RESTful search and analytics engine capable of solving a growing number of use cases.
НС>С сайта авторов.
Ты ж говорил, что не хочешь обсуждать терминологию... Ну да ладно.
Потому что nosql это терминология, часто мало что говорящая, помещать такое на главную страницу — какое-то хипстерство было бы. Но вот тебе сайт авторов: https://www.elastic.co/blog/found-elasticsearch-as-nosql https://www.elastic.co/videos/just-eat-journey-nosql-elasticsearch
Ну и ознакомься с этим списочком: https://en.wikipedia.org/wiki/Document-oriented_database#Implementations
Т.е. по общепринятой терминологии ES это document oriented nosql database.
А ты так до сих пор и не объяснил свою терминологию. Что по-твоему такое nosql и назови продукты, которые им являются.
НС>>>·>Давай теперь выясним что называть фичей nosql? И особенно интересно что называть "полезной фичей". НС>>>Спор о терминах? Без меня. НС>·>Ты только что заявил, что ES не является nosql, потому что в нём нет визуализатора. НС>Вранье.
Ты сказал что ELK это nosql, а ES — нет. А ELK это банально ES интегрированный с Logstash и Kibana. Я всё правильно понял?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Тонкий намёк: Structured QUERY Language.
Мы уже победили, просто это еще не так заметно...
