Писать посты на тему Caché можно не только в блог InterSystems, и не только силами сотрудников, хабр — социальный проект.
Про «рецепты из вики», это стиль подачи информации в статье. Как яркий пример такой статьи, wiki.openstreetmap.org/wiki/PostGIS/Installation — вся статья — концентрированный личный опыт. Какие команды выполнить, чтобы достичь результата. Ориентировано исключительно на тех, кто знает, что и с помощью чего он собирается делать. Вот только я пока совсем не вижу причин, по которым кому-нибудь вообще стоит использовать Caché. И это проблема не моя, а компании InterSystems, потому что возьму я в зависимости от задачи PostgreSQL или Redis, а не их разработку.
Знаете, показателем полезности ваших статей является, например, то, что они не набирали больше +6 (а это меньше, чем сотрудников InterSystems на хабре!), и то, что в комментариях к ним (в основном «отличная статья! автору респект!») не отметилось никого, кроме сотрудников того же InterSystems.
Если вы хотите увеличивать тусовку людей, то, может быть, стоит задуматься, что и для кого вы пишете на хабре?
Понимаете, в чём проблема.
Я вот пересмотрел все посты из Хабра на тему Caché.
Подавляющее большинство написано людьми, работающими в InterSystems.
Подавляющее большинство постов никогда не выходило в топ Хабра.
Подавляющее большинство постов выглядит, как копипаста рецептов из вики, за исключением того, что никакой вики про Caché мне найти не удалось.
В комментариях тусит небольшая тусовка людей, которые оказываются в основном сотрудниками того же InterSystems.
Так что, обращаясь к сотрудникам InterSystems: можно _хороший_ пост _для непосвящённых_, в котором _внятно_ будет объяснено, что такое Caché и зачем его нужно иметь где-то, кроме легаси-кода?
Что такое Caché?
Зачем оно нужно?
Почему у него такое мудрёное название?
Чем оно отличается от постгреса, монги, редиса?
Какого чёрта я должен думать о том, как там внутри представляются числа?
Тест на ntpdate некорректен.
Во-первых, никак не учтена вероятность того, что за время исполнения теста может измениться секунда.
Во-вторых, нет проверки того, что время было выставлено правильно именно из-за вызова ntpdate — как минимум, нужна проверка на то, что время хоста и девайса не совпадают до вызова, а возможно и сброс времени девайса в начале.
«Неудачный город» — отличное обоснование для причины опоздания на обратный самолёт в командировке, когда нечаянно заблудитесь по дороге в аэропорт, а интернета для карт не будет.
А потом вы ещё выясните, что создали не район города, а район области, и поломали иерархию вложенности для адресов, как уже было пару лет назад на запуске в Минске.
В плане документации для новичков osm.org/, как ни странно, сильно лучше, со своим Wiki.
Пользователь «потерял» телефон — телефон продали на рынке — производитель не получил денег за новый телефон, который мог бы купить человек, который купил на рынке ворованный.
Всё-таки PostgreSQL — это не просто реляционная, это объектно-реляционная СУБД. И мне достаточно сложно представить, как она может выпасть из рассмотрения.
Таким образом, вычитка звёздочки приводит к множественным seek-ам на диске.
После этого данные надо отдать в ваше приложение, в лучшем случае — записав в сокет и вычитав из него (ещё два копирования в памяти), а если у вас используется какая-то ORM — то ещё и происходит раскладывание полей по объекту.
> SELECT * FROM posts субъективно будет работать быстрее чем SELECT id, poster_url FROM posts
простите, почему это? длинный текст поста, лежащий где-то в недрах TOAST-таблиц, постгресу вытаскивать сильно медленнее, чем быстро отдавать короткий урл и id.
Про «рецепты из вики», это стиль подачи информации в статье. Как яркий пример такой статьи, wiki.openstreetmap.org/wiki/PostGIS/Installation — вся статья — концентрированный личный опыт. Какие команды выполнить, чтобы достичь результата. Ориентировано исключительно на тех, кто знает, что и с помощью чего он собирается делать. Вот только я пока совсем не вижу причин, по которым кому-нибудь вообще стоит использовать Caché. И это проблема не моя, а компании InterSystems, потому что возьму я в зависимости от задачи PostgreSQL или Redis, а не их разработку.
Знаете, показателем полезности ваших статей является, например, то, что они не набирали больше +6 (а это меньше, чем сотрудников InterSystems на хабре!), и то, что в комментариях к ним (в основном «отличная статья! автору респект!») не отметилось никого, кроме сотрудников того же InterSystems.
Если вы хотите увеличивать тусовку людей, то, может быть, стоит задуматься, что и для кого вы пишете на хабре?
Я вот пересмотрел все посты из Хабра на тему Caché.
Подавляющее большинство написано людьми, работающими в InterSystems.
Подавляющее большинство постов никогда не выходило в топ Хабра.
Подавляющее большинство постов выглядит, как копипаста рецептов из вики, за исключением того, что никакой вики про Caché мне найти не удалось.
В комментариях тусит небольшая тусовка людей, которые оказываются в основном сотрудниками того же InterSystems.
Так что, обращаясь к сотрудникам InterSystems: можно _хороший_ пост _для непосвящённых_, в котором _внятно_ будет объяснено, что такое Caché и зачем его нужно иметь где-то, кроме легаси-кода?
Зачем оно нужно?
Почему у него такое мудрёное название?
Чем оно отличается от постгреса, монги, редиса?
Какого чёрта я должен думать о том, как там внутри представляются числа?
Во-первых, никак не учтена вероятность того, что за время исполнения теста может измениться секунда.
Во-вторых, нет проверки того, что время было выставлено правильно именно из-за вызова ntpdate — как минимум, нужна проверка на то, что время хоста и девайса не совпадают до вызова, а возможно и сброс времени девайса в начале.
Даблклик левой кнопкой — приблизить. Даблклик правой кнопкой — отдалить. Скролл — зумить.
На ноутбуке:
Правая кнопка — тап двумя пальцами на тачпаде.
На телефоне:
Даблтап одним пальцем — приблизить. Даблтап двумя пальцами — отдалить.
В общем-то, простой перенос концепции. Нашёл сам, подсознательно.
В плане документации для новичков osm.org/, как ни странно, сильно лучше, со своим Wiki.
www.postgresql.org/docs/9.1/static/pgtrgm.html
Всё-таки PostgreSQL — это не просто реляционная, это объектно-реляционная СУБД. И мне достаточно сложно представить, как она может выпасть из рассмотрения.
В PostgreSQL, к примеру, поля длиннее 8 кб сначала пытаются скомпрессироваться, чтобы влезть в 8 кб, а потом выносятся во внешние, спрятанные от юзера TOAST-таблицы:
www.postgresql.org/docs/9.3/interactive/storage-toast.html
Таким образом, вычитка звёздочки приводит к множественным seek-ам на диске.
После этого данные надо отдать в ваше приложение, в лучшем случае — записав в сокет и вычитав из него (ещё два копирования в памяти), а если у вас используется какая-то ORM — то ещё и происходит раскладывание полей по объекту.
простите, почему это? длинный текст поста, лежащий где-то в недрах TOAST-таблиц, постгресу вытаскивать сильно медленнее, чем быстро отдавать короткий урл и id.