Помнится, не так давно кому-то захотелось пересчитать все рассчёты в пейперах на какую-то тему, и обнаружилось, что исходных данных нет у примерно 80% работ. Вернее, они есть, но «где-то у кого-то на флешке неизвестно где, если мы ещё не переписали поверх новой версией скрипта или не потёрли». А что, пейпер-то написан, делов-то, кто проверять будет.
На данный момент у меня нет оснований верить ни единому слову из поста, потому что я даже не знаю, каким способом вы выщемливали из всего многообразия телефонные разговоры, например, и не приписали ли нечаянно к телефонным разговорам ещё что-нибудь.
Postgres. Одна s. Я же не ленюсь проставлять é в Caché :)
Привязка nginx — это всего лишь способ сменить протокол передачи данных с протокола БД на http, да расписать способы преобразования. Это можно заменить даже shell cgi-скриптом.
Суть примера в том, что в базе есть всё для организации REST API, включая лёгкий парсинг и сериализацию json.
В Caché, судя по статье, вырвиглазная комбинация всего подряд:
— роуты http->function пишутся в XML-подобном стиле;
— классы оборачиваются в C-like скобочки;
— сам язык напоминает привет из детства (привет, qbasic и отмечание типа переменной %$@), только во много раз хуже (скажите, зачем в quit $$$OK аж трёхзначная сумма долларов?);
— сериализация в json методом конкатенации строк, забытая всеми… везде?
— конфигурация в окошках (я посмотрю, как вас будут любить админы, которые будут раскатывать 200 инстансов базы по серверам c помощью chef/puppet...)
— метод GetGridData вообще пишет дебажные логи в не-json формате в выходной канал. Способов логирования ошибок система не предоставляет?
Скажите, существуют ли вообще примеры не-говнокода на Caché? Пока что я таких не видел — в статьи-то на хабр, наверное, самое классное и вкусное пишется?
(Кстати, спасибо за статью — в процессе написания комментария проверил, обнаружил, что геометрические типы в postgis не сериализовались в geojson, оставаясь в текстовом WKB, запилил и заслал патч из двух строчек.)
Чтобы узнать, работает ли человек в InterSystems, достаточно пойти в профиль человека и найти строку «Работаю в InterSystems». Таковыми являются почти все авторы статей про Caché на хабре. Новости пишет только корпоративный аккаунт intersystems.
«Доктор не мыл руки перед операцией, потому что в ней акцент делался на другом, на вырезании аппендицита.»
Почему вы их не использовали, если они есть?
Они неудобны, некрасивы, глючны, или вы просто ими никогда не пользовались?
Во всех современных системах сделать json-представление чего угодно значительно быстрее, проще и безопаснее через специально для этого созданные средства.
Стилистика InterSystems Caché осталась в девяностых?
ВСЁ.
В этом примере:
— формирование корректного json;
— безопасность регулируется на двух уровнях: права доступа конкретного пользователя в postgresql, и права доступа к урлам на nginx;
— формирование любой структуры данных автоматически — hstore / json / jsonb-поля в базе автоматически свернутся в своё правильное представление.
Скажите, почему в системе, работающей и предлагающейся к использованию в 2014 году до сих пор нет средств простого сворачивания произвольной структуры в json, а разработчики (разработчики самой системы, сотрудники InterSystems) пользуются для её имитации конкатенацией строк?
В PostgreSQL планировщик запросов достаточно умён, чтобы в подавляющем большинстве случаев оптимизировать план запроса под ваши данные на основе статистики по таблицам, развернуть Join в другую сторону, выбрать правильный алгоритм join'а, и вообще «сделать хорошо». Ошибки редки и в большинстве своём чинятся чтением EXPLAIN (ANALYZE) от запроса, хлопаньем себя по лбу и высказыванием «вот я дурак» (обычно 1..10 минут).
Что такое в случае Caché «оптимизировать SQL самостоятельно»? Какие инструменты кроме EXPLAIN / ANALYZE / auto_explain для этого могут быть в принципе нужны? Значит ли это, что при выборе Caché на самом деле у меня нет опции писать на SQL, и всё придётся переписывать на вендор-лоченом собственном языке, с которого просто некуда мигрировать?
По поводу SQL и NoSQL: стандартная нынче архитектура высоконагруженной системы обычно включает в себя:
— frontend, штука, которая очень быстро асинхронно общается с пользователем — пишется самостоятельно, иногда может выродиться в конфиг nginx;
— cache, in-memory key-value хранилище с экспайрингом, обычно redis/memcache, хранящее наиболее популярные read-запросы к фронтенду (используется, когда у приложения большой read);
— mq, брокер очередей сообщений — штука, которая занимается асинхронностью и распределением нагрузки по узлам, в которую фронтенд складирует write-запросы и прочие вызовы долгих процедур (используется, соответственно, при наличии большого потока на write; обычно rabbitmq / rq);
— worker, который разгребает queue и выполняет все долгие записи и рассчёты, а зачастую и заполняющий кеш — пишется самостоятельно;
— persistent storage, база данных-хранилка, в которой надёжно лежат все данные — вот тут уже кто во что горазд, postgresql / mysql / mongodb.
Из комментариев ниже я понял, что Caché претендует на то, чтобы быть frontend и persistent storage. А что у него с кешем в памяти? Может ли Caché удобно и эффективно менеджить очередь сообщений (вообще, есть ли там понятие сообщений?)
«Но мне вполне хватает Caché, чего не хватает сами делаем.» — пугающая фраза.
Значит ли это, что при выборе Caché как базы я обречён становиться её разработчиком?
Идут ли в комплекте с лицензией исходные тексты Caché?
Значит ли это, что при использовании Caché у меня перестанет хватать времени на самообразование и я не смогу эффективно разрабатывать систему, потому что я не смогу брать готовые блоки и мне придётся всё переписывать заново?
В хорошей high-load архитектуре вся фишка как раз в том и состоит — время на оптимизацию не тратится, кроме совсем критических перформанс-проседаний, которые уже считаются багами, «потому что один идиот заселектил всю таблицу и фильтрует её в коде».
Пока что я вижу, что этот самый быдлокодерский кошмарный сон DBA в Caché считается подходом по умолчанию, и это сеет недоверие к продукту.
«Для новичков в Caché» — вовсе не то же самое, что «для клинических идиотов», и вовсе не подразумевает отсутствия бекграундовых знаний в других технологиях и проблем, с которыми сталкиваются все, кто так или иначе реализует заявленные InterSystems фичи.
У меня вполне конкретный список вопросов, не рассмотренных в обозримых интернетах, кратко озвученный ещё в самом первом комментарии, на который мне было предложено «пойти погуглить».
Суть: «всё, что угодно, можно представить в виде набора вложенных словарей».
В общем-то, просто, очевидно и понятно.
Непонятно, как этот словарь будет крутиться, когда в него положить пару миллионов значений, а потом достать?
Что будет, когда мы захотим обновить половину значений в половине ключей на втором-третьем уровне вложенности?
С какой стороны к этому прикручена транзакционность?
Как оно будет хранить это всё на нескольких узлах, когда всё место на одном закончится?
Как оно будет балансировать нагрузку на чтение-запись?
В общем-то, самое интересное остаётся за кадром.
А представленное в статье в питоне легко делается через d = json.load(file) / global d / json.dump(file, d), без всякого Caché.
Простите, но если главное в статье для новичков находится на семнадцатом нажатии PgDn из 48, то к качеству этой статьи у меня есть определённые претензии, которые hivemind хабра выражает проще — рейтинг поста — +1.
Тем более, что из приведённой вами цитаты с зашкаливающим количеством умных слов мне совсем неясно, в чём отличие от Redis и его хранимок на lua.
Представляете, этот пост чуть менее, чем полностью, состоит из скриншотов мастеров, которые я увижу всего один раз, если вообще увижу. За деревьями не видно леса.
И в комментах опять одни сотрудники InterSystems, и потерявшиеся нечаянно попавшие люди, ничего не знающие про Caché, вежливо намекающие, что ничего не поняли, но, может быть, круто. Правда, непонятно, как это может пригодиться в жизни.
Но как пример того, что посты можно писать по-разному, и не обязательно в корпоративный блог — хорошо!
Как-то так и должен выглядеть вводный пост про то, что такое Caché и как его набирать с клавиатуры :)
За пятнадцать лет успело смениться минимум три поколения программистов. Вы правда думаете, что кто-то читает статьи пятнадцатилетней давности? В лучшем случае — свежие их переводы :)
Вот, когда напишете первый пост (а скелет вы уже написали) — есть сразу несколько вопросов на потом (нет, не нужно отвечать тут сейчас, напишите красивый отдельный пост):
1. если Caché умеет работать, как редис — как это сделать? как писать ин-мемори без транзакций, в стиле r.get() / r.set()? как оно обходится с памятью? что будет, когда память кончится? как рассказать «убивай всё старое и не держи на него зла, ты кеш»? как экспайрить и продлевать время жизни записей?
2. если Caché умеет косить под Postgres / SQL — как это использовать? как отличить Caché-[redis] от Caché-[postgres]? насколько реально взять какой-нибудь несложный движок/ORM и сходу запустить под Caché? Вот чисто ради примера — какой-нибудь простой Django app или Wordpress.
3. если Caché умеет работать, как Mongo — интересно было бы почитать, как оно масштабируется. Не «запустите вот такую команду, чтобы смасштабировать на два сервера», а нормальные схемы, как происходит чтение, запись в репликах, куда пишется WAL и что происходит, когда сеть падает и вдруг Split-brain и merge-brain.
И, ради бога, не используйте никому неизвестных маркетинговых термиров в статьях для новичков. «Вместе с Caché поставляется технология NLP iKnow и технология OLAP DeepSee.» — пустой звук для меня, пока вы не расскажете, что это и почему я его хочу.
Топик называется «Алгоритмы устранения ложных и избыточных данных в GPS-потоке», а рассказано только про избыточные данные.
Как фильтровать «узелки» на стоянках?
Скажите, а зачем там переход в UTM вообще? Расстояния куда лучше считать напрямую из градусов координат.
А как оно обрабатывает переход через 360 градусов?
И положите исходники на гитхаб, что ли.
Помнится, не так давно кому-то захотелось пересчитать все рассчёты в пейперах на какую-то тему, и обнаружилось, что исходных данных нет у примерно 80% работ. Вернее, они есть, но «где-то у кого-то на флешке неизвестно где, если мы ещё не переписали поверх новой версией скрипта или не потёрли». А что, пейпер-то написан, делов-то, кто проверять будет.
На данный момент у меня нет оснований верить ни единому слову из поста, потому что я даже не знаю, каким способом вы выщемливали из всего многообразия телефонные разговоры, например, и не приписали ли нечаянно к телефонным разговорам ещё что-нибудь.
Привязка nginx — это всего лишь способ сменить протокол передачи данных с протокола БД на http, да расписать способы преобразования. Это можно заменить даже shell cgi-скриптом.
Суть примера в том, что в базе есть всё для организации REST API, включая лёгкий парсинг и сериализацию json.
В Caché, судя по статье, вырвиглазная комбинация всего подряд:
— роуты http->function пишутся в XML-подобном стиле;
— классы оборачиваются в C-like скобочки;
— сам язык напоминает привет из детства (привет, qbasic и отмечание типа переменной %$@), только во много раз хуже (скажите, зачем в quit $$$OK аж трёхзначная сумма долларов?);
— сериализация в json методом конкатенации строк, забытая всеми… везде?
— конфигурация в окошках (я посмотрю, как вас будут любить админы, которые будут раскатывать 200 инстансов базы по серверам c помощью chef/puppet...)
— метод GetGridData вообще пишет дебажные логи в не-json формате в выходной канал. Способов логирования ошибок система не предоставляет?
Скажите, существуют ли вообще примеры не-говнокода на Caché? Пока что я таких не видел — в статьи-то на хабр, наверное, самое классное и вкусное пишется?
(Кстати, спасибо за статью — в процессе написания комментария проверил, обнаружил, что геометрические типы в postgis не сериализовались в geojson, оставаясь в текстовом WKB, запилил и заслал патч из двух строчек.)
Чтобы узнать, работает ли человек в InterSystems, достаточно пойти в профиль человека и найти строку «Работаю в InterSystems». Таковыми являются почти все авторы статей про Caché на хабре. Новости пишет только корпоративный аккаунт intersystems.
Почему вы их не использовали, если они есть?
Они неудобны, некрасивы, глючны, или вы просто ими никогда не пользовались?
Во всех современных системах сделать json-представление чего угодно значительно быстрее, проще и безопаснее через специально для этого созданные средства.
Стилистика InterSystems Caché осталась в девяностых?
— Написать запрос, вытаскивающий всё, что нужно, сразу же правильно упаковывающий в json, эскейпящий все значения и делающий хорошо:
— Написать конфиг nginx, который скажет, как раздать postgres по http:
(пример утащен с https://github.com/FRiCKLE/ngx_postgres)
ВСЁ.
В этом примере:
— формирование корректного json;
— безопасность регулируется на двух уровнях: права доступа конкретного пользователя в postgresql, и права доступа к урлам на nginx;
— формирование любой структуры данных автоматически — hstore / json / jsonb-поля в базе автоматически свернутся в своё правильное представление.
Скажите, почему в системе, работающей и предлагающейся к использованию в 2014 году до сих пор нет средств простого сворачивания произвольной структуры в json, а разработчики (разработчики самой системы, сотрудники InterSystems) пользуются для её имитации конкатенацией строк?
Пользуясь вашей терминологией: хотите знать больше, гуглите.
Что такое в случае Caché «оптимизировать SQL самостоятельно»? Какие инструменты кроме EXPLAIN / ANALYZE / auto_explain для этого могут быть в принципе нужны? Значит ли это, что при выборе Caché на самом деле у меня нет опции писать на SQL, и всё придётся переписывать на вендор-лоченом собственном языке, с которого просто некуда мигрировать?
По поводу SQL и NoSQL: стандартная нынче архитектура высоконагруженной системы обычно включает в себя:
— frontend, штука, которая очень быстро асинхронно общается с пользователем — пишется самостоятельно, иногда может выродиться в конфиг nginx;
— cache, in-memory key-value хранилище с экспайрингом, обычно redis/memcache, хранящее наиболее популярные read-запросы к фронтенду (используется, когда у приложения большой read);
— mq, брокер очередей сообщений — штука, которая занимается асинхронностью и распределением нагрузки по узлам, в которую фронтенд складирует write-запросы и прочие вызовы долгих процедур (используется, соответственно, при наличии большого потока на write; обычно rabbitmq / rq);
— worker, который разгребает queue и выполняет все долгие записи и рассчёты, а зачастую и заполняющий кеш — пишется самостоятельно;
— persistent storage, база данных-хранилка, в которой надёжно лежат все данные — вот тут уже кто во что горазд, postgresql / mysql / mongodb.
Из комментариев ниже я понял, что Caché претендует на то, чтобы быть frontend и persistent storage. А что у него с кешем в памяти? Может ли Caché удобно и эффективно менеджить очередь сообщений (вообще, есть ли там понятие сообщений?)
«Но мне вполне хватает Caché, чего не хватает сами делаем.» — пугающая фраза.
Значит ли это, что при выборе Caché как базы я обречён становиться её разработчиком?
Идут ли в комплекте с лицензией исходные тексты Caché?
Значит ли это, что при использовании Caché у меня перестанет хватать времени на самообразование и я не смогу эффективно разрабатывать систему, потому что я не смогу брать готовые блоки и мне придётся всё переписывать заново?
В хорошей high-load архитектуре вся фишка как раз в том и состоит — время на оптимизацию не тратится, кроме совсем критических перформанс-проседаний, которые уже считаются багами, «потому что один идиот заселектил всю таблицу и фильтрует её в коде».
Пока что я вижу, что этот самый быдлокодерский кошмарный сон DBA в Caché считается подходом по умолчанию, и это сеет недоверие к продукту.
У меня вполне конкретный список вопросов, не рассмотренных в обозримых интернетах, кратко озвученный ещё в самом первом комментарии, на который мне было предложено «пойти погуглить».
Суть: «всё, что угодно, можно представить в виде набора вложенных словарей».
В общем-то, просто, очевидно и понятно.
Непонятно, как этот словарь будет крутиться, когда в него положить пару миллионов значений, а потом достать?
Что будет, когда мы захотим обновить половину значений в половине ключей на втором-третьем уровне вложенности?
С какой стороны к этому прикручена транзакционность?
Как оно будет хранить это всё на нескольких узлах, когда всё место на одном закончится?
Как оно будет балансировать нагрузку на чтение-запись?
В общем-то, самое интересное остаётся за кадром.
А представленное в статье в питоне легко делается через d = json.load(file) / global d / json.dump(file, d), без всякого Caché.
Тем более, что из приведённой вами цитаты с зашкаливающим количеством умных слов мне совсем неясно, в чём отличие от Redis и его хранимок на lua.
И в комментах опять одни сотрудники InterSystems, и потерявшиеся нечаянно попавшие люди, ничего не знающие про Caché, вежливо намекающие, что ничего не поняли, но, может быть, круто. Правда, непонятно, как это может пригодиться в жизни.
Но как пример того, что посты можно писать по-разному, и не обязательно в корпоративный блог — хорошо!
— геометрические операции следует выполнять на эллипсоиде;
— отображать результаты можно как угодно.
Как-то так и должен выглядеть вводный пост про то, что такое Caché и как его набирать с клавиатуры :)
За пятнадцать лет успело смениться минимум три поколения программистов. Вы правда думаете, что кто-то читает статьи пятнадцатилетней давности? В лучшем случае — свежие их переводы :)
Вот, когда напишете первый пост (а скелет вы уже написали) — есть сразу несколько вопросов на потом (нет, не нужно отвечать тут сейчас, напишите красивый отдельный пост):
1. если Caché умеет работать, как редис — как это сделать? как писать ин-мемори без транзакций, в стиле r.get() / r.set()? как оно обходится с памятью? что будет, когда память кончится? как рассказать «убивай всё старое и не держи на него зла, ты кеш»? как экспайрить и продлевать время жизни записей?
2. если Caché умеет косить под Postgres / SQL — как это использовать? как отличить Caché-[redis] от Caché-[postgres]? насколько реально взять какой-нибудь несложный движок/ORM и сходу запустить под Caché? Вот чисто ради примера — какой-нибудь простой Django app или Wordpress.
3. если Caché умеет работать, как Mongo — интересно было бы почитать, как оно масштабируется. Не «запустите вот такую команду, чтобы смасштабировать на два сервера», а нормальные схемы, как происходит чтение, запись в репликах, куда пишется WAL и что происходит, когда сеть падает и вдруг Split-brain и merge-brain.
И, ради бога, не используйте никому неизвестных маркетинговых термиров в статьях для новичков. «Вместе с Caché поставляется технология NLP iKnow и технология OLAP DeepSee.» — пустой звук для меня, пока вы не расскажете, что это и почему я его хочу.
И спасибо за ответ! :)