×Закрыть

Последние комментарии

  • В ночь с пятницы на воскресенье, или Затертые изменения

    Не «гарантировать» но «помочь» и «дать базу для» а именно хорошая гранулированность изменений как один из принципов процесса никаких «сверх-мега-супер-кода-дроп за последние 2 недели моей работы!» (к) (тм)

    ЗЫ: опять таки палки об разных концах но минимальные тесты также помогают.

    ЗЫ: опять таки палки об разных концах и вдумчивый отстрел самых умных которых делают не анализ конкретного изменения а анализ собственных мыслей по поводу кода вообще также крайне полезен и настоятельно рекомендуем.

  • DevOps дайджест #12: сравнение оркестраторов, микросервисы на Go и что у Uber под капотом

    Давно пора. DevOps термін віддає светром і бородою в захламленій кімнаті.

  • Not Only SQL: ищем альтернативы реляционным базам

    При желании я могу нагенерировать записей в таблицу «друзей» до глубины 128, к примеру, или сколько нужно? Графовый подход может быть более эффективным в случае, если есть несколько взаимосвязанных иерархий.

    Я сбросил выше статистику, которая показывает что не только, формально там рассмотрен наш пример с обходом просто графа без каких либо вычислений связанных с атрибутами узлов или отношений. Чем глубже граф и чем больше в нем узлов тем более ваш рекурсивный CTE выполнит обращений к общему индексу/таблице по всем отношениям и тем медленее будет время запроса — что впринципе логично.

    Это решается правильным выбором структуры хранения данных, возможно, частичной денормализацией. Что же касается действительно реальных запросов, то как только мы добавим в картину необходимость сортировать данные (внутри запроса или в процессе выдачи пользователю), возможность многопользовательской работы, согласованность данных, то какое решение будет лучше?
    Графовые базы так же декларируют ACID и даже поддерживают сортировку результирующего набора. Что же касаеться транзакций, неуверен насколько они с этим эффективно справляються, но для меня выбор неочевиден, хотя РСУБД в этом однозначно должны по идее преуспевать. Я с трудом представляю задачи где может потребоваться, что называеться consistency без малейшего посыла к soft state и одновременно использование графовой базы для анализа — сомнительное преимущество. Я больше бы опасался проблем, которые у вас возникнут при обновлении графа, который храниться в денормализированном представлении в реляционной СУБД, особенно если у вас появиться необходимость работать с нескалярными атрибутами при анализе графа и как это будет влиять на эффективность чтения.
    Опять же — развитие схемы данных, изменение требований к выдаче данных, развитие проекта. Иерархический запрос можно написать (и изменить) за считанные минуты.
    Рекурсивный CTE и SQL занял значительно больше кода нежели тоже самое на cypher для поиска друзей из примера выше. У некоторых вендоров вообще нет инструментария для работы с рекурсивными запросами в SQL, и требует значительных усилий\написания процедурного кода.

    У графовых баз есть несомненно один неоспоримый недостаток — это сложность поиска людей, которые будут с ней работать, по сравнению с реляционной, но даже при таком положении вещей я бы задумался прежде чем писать обработку графа в SQL для задачи, где это действиительно необходимо.

  • Ловушки мышления в тестировании

    Вы правы, возможно я не так донесла и сформулировала пример в иллюзорной корелляции. В чем-то я согласна с вами, что пример Билла Гейтса и Марка Цукерберга можно было бы отнести к ошибке выжившего, если бы у нас вообще не было возможности получить информацию о других. Билла Гейтса и Марка Цукерберга бросили колледж — достигли многого. Человек бросил ВУЗ — сейчас построил свой бизнес. Иллюзоная корреляция в том, что считают, что человек достиг многого, т.к бросил учебу, а не потому, что он гений.

  • Ловушки мышления в тестировании

    Спасибо. Теперь понятно. Просто вы ошиблись с примером в иллюзорной корреляции. Он явно относится к ошибке выжившего. Поэтому я и спросил.
    Вот что вы написали:

    Люди нередко проводят иллюзорные корреляции в различных областях жизни. Вспомним, хотя бы, Билла Гейтса и Марка Цукерберга, бросивших учебу и основавших многомиллиардный бизнес. И мы помним эти случаи, ставим их в пример. Но слышали ли мы истории недоучившихся студентов, не создавших всемирно известные компании? Нет. В потоке информации мы заостряем внимание на экстраординарных случаях, игнорируя остальные.
  • Рост зарплат с опытом работы: аналитика

    Скоріше за все, під сфітом мали на увазі iOS Developing. Хоча й самому цікаво, що ж там в 2019 :)

  • DevOps дайджест #12: сравнение оркестраторов, микросервисы на Go и что у Uber под капотом

  • Not Only SQL: ищем альтернативы реляционным базам

    Это немного странно, заявлять о чем-то, но не иметь возможности подкрепить какими-то своими результатами или подтвержденными результатами других людей, не?
    Вам сбросить сравнение фич вендора документной баз с ссылкой на msdn? Или университетский учебник по алгоритмам и структурам данных? Такой вариант может лучше подойдет?

    Более того у нас есть утверждение с которого все и началось —

    Ієрархії, свого часу були Охілесовою п’ятою реляційних БД, і їх реалізацію вирішували багатьма алгоритмами, від Parent-Child до Nested Set. Ще більшою була проблема невизначеності можливої кількості та складу полів. З появою JSON / BSON полів ці проблеми стали перевагами, як і імплементація шардінґу.
    Мы пока не имеем никакого подтверждения этому.
    Данные хранились в сериализованном виде в CLOB-полях, которые затем трансформировались в стандартные VARCHAR-ы, и затем часть данных извлекалась оттуда и хранилась в виде коллекций, или CSV. Часть данных трансформировалась в реляционную форму, часть оставалась в таком полусериализованном виде. Для преобразований существовали стандартные и собственные типы. Все это можно реализовать в SQL. Естественно, чем «чище» SQL, тем лучше производительность, поэтому встроенная поддержка подобных вещей существенно облегчает и решение задачи, и дальнейшее сопровождение.

    Я сталкивался с таким — обычно это переписываеться все с использование серверных языков со статической типизацией, с нормальной поддержкой локалей, типов данных и удобной настройкой сериализиторов, а не ждут расширения SQL API. Вы пытаетесь применить декларативный язык для работы с реляционными структурами данных для того что бы парсить и десериализировать, а потом сереализировать — совсем не по назначению.

  • Not Only SQL: ищем альтернативы реляционным базам

    Окей, то есть, сначала:

    Возможности документных баз шире чем возможность писать sql для json поля — про скорость таких решений я вообще молчу.
    А сейчас:
    Под рукой ничего нету для сравнения скорости
    Это немного странно, заявлять о чем-то, но не иметь возможности подкрепить какими-то своими результатами или подтвержденными результатами других людей, не?
    о я априори не ожидаю, что если есть сериализированный документ в поле и таблица вы сможете эффективно применять к этому SQL для типичных задач реляционных баз

    JSON in MSSQL: msdn.microsoft.com/…​-us/library/dn921897.aspx
    JSON in Oracle: blogs.oracle.com/…​es_json_within_the_oracle

    Я лично с JSON в базе не сталкивался, но с сериализованными данными работал и работаю.
    Например, одна из задач была — хранение и подготовка отчетов по данным аудита из разных приложений. Данные хранились в сериализованном виде в CLOB-полях, которые затем трансформировались в стандартные VARCHAR-ы, и затем часть данных извлекалась оттуда и хранилась в виде коллекций, или CSV. Часть данных трансформировалась в реляционную форму, часть оставалась в таком полусериализованном виде. Для преобразований существовали стандартные и собственные типы. Все это можно реализовать в SQL. Естественно, чем «чище» SQL, тем лучше производительность, поэтому встроенная поддержка подобных вещей существенно облегчает и решение задачи, и дальнейшее сопровождение.

  • Not Only SQL: ищем альтернативы реляционным базам

    Я вижу ничего более чем то, что ваш пк может быстро 17 раз найти по индексу данные в целочисленном поле и небольшой таблиц

    Вообще-то оба запроса — это обход дерева. Первый запрос — полный обход дерева, второй — от конкретного узла, проход поддерева. Это аж никак не «17 раз найти по индексу данные». Да, это просто дерево без реального наполнения. Добавление «полезной нагрузки» в дерево не увеличит существенно время выполнения этих запросов, присоединение таблиц с «реальными данными» в контексте таких запросов вообще не влияет.
    Например, с соединением к таблице пользователей:

    SQL> ed
    Wrote file afiedt.buf
    
      1  with fr (user_1, user_2, hlevel) as (
      2  select user_1, user_2, 1 from t_user_friend
      3    where  user_1=2
      4    union all
      5    select e.user_1, e.user_2, m.hlevel + 1 from  t_user_friend e
      6    join  fr m  on (m.user_2 = e.user_1)
      7  ) select count(distinct t.name) from fr
      8* join t_user t on t.id=fr.user_2
    SQL> /
    
    COUNT(DISTINCTT.NAME)
    ---------------------
                     1294
    
    Elapsed: 00:00:00.72
    SQL> ed
    Wrote file afiedt.buf
    
      1  with fr (user_1, user_2, hlevel) as (
      2  select user_1, user_2, 1 from t_user_friend
      3    where  user_1=2
      4    union all
      5    select e.user_1, e.user_2, m.hlevel + 1 from  t_user_friend e
      6    join  fr m  on (m.user_2 = e.user_1)
      7  ) select count(t.name) from fr
      8* join t_user t on t.id=fr.user_2
    SQL> /
    
    COUNT(T.NAME)
    -------------
             1300
    
    Elapsed: 00:00:00.02
    
    При желании я могу нагенерировать записей в таблицу «друзей» до глубины 128, к примеру, или сколько нужно? Графовый подход может быть более эффективным в случае, если есть несколько взаимосвязанных иерархий. К примеру, если есть дерево объектов, и атрибуты объектов связаны между собой, в этом случае эффективность выборки данных будет очень сильно зависеть от пути доступа к данным, или от плана выполнения. Это решается правильным выбором структуры хранения данных, возможно, частичной денормализацией. Что же касается действительно реальных запросов, то как только мы добавим в картину необходимость сортировать данные (внутри запроса или в процессе выдачи пользователю), возможность многопользовательской работы, согласованность данных, то какое решение будет лучше?
    Опять же — развитие схемы данных, изменение требований к выдаче данных, развитие проекта. Иерархический запрос можно написать (и изменить) за считанные минуты.
  • Not Only SQL: ищем альтернативы реляционным базам

    Какие возможности имеются в виду и можно какую-то поддержку слов про «скорость таких решений»?
    Под рукой ничего нету для сравнения скорости, но я априори не ожидаю, что если есть сериализированный документ в поле и таблица вы сможете эффективно применять к этому SQL для типичных задач реляционных баз — эффективно обновить данные в рамках транзакции, сделать группировку, фильтрацию по группе критериев и т.д. предварительно не добавив индекс под каждую отдельную задачу(что наверняка повлечет либо дубликацию данных либо вынесение указателей в ндекс из сериализированного json). А как у нас обстоят дела с индексами кстати? они уже имеют делать групповые и сложные индексы, гео-индексы по атрибутам и т.д. — вообщем типичные вещи для документных баз(как раз таки те самые широкие возможности документных баз).

    Я бы Sql + json документ формулу использовал как можно реже впринципе, и без крайней надобности старался не применять. Я с трудом представляю, что может быть хорошей идей взять таблицу и какой-то сериализированный Json обьект и начать искать в нем что-то или joinнить с чем-то в других таблицах, фильтровать, групировать и вообще делать любые операции с данными привязываясь к структуре таблиц и неструктурированного Json поля и все это обрабатывать в sql.
    Для меня это звучит во многом бессмысленно — возможно у вас есть хорошие use кейсы, что оправдали себя на практике, охотно ознакомлюсь.

  • Not Only SQL: ищем альтернативы реляционным базам

    но я надеюсь понятно, что это дешевая операция?
    Она быстрая в контексте размеры бд, количества обьединений и мощности рабочей станции — но это говорит мало о чем в контексте подхода. Я вижу ничего более чем то, что ваш пк может быстро 17 раз найти по индексу(или сделать table scan) данные в целочисленном поле и небольшой таблице — ок.
    Суть глобально же это не меняет поиск в реляционной подход будет прямопропорционально медленней работать размеру базы, в отличии от графовой базы.
    pdfs.semanticscholar.org/…​d6f79547fef9407262dbf.pdf
    Тут было бы конечно интересно поднять действительно большую базу и сравнить с поиском в глубоком графе. Про читабельность запроса, когда надо в реляционном представлении обойти граф так же говорить не приходиться.
  • Пособие для будущего Java разработчика. Основы Java

    Начинать с Прототипно ориентированого языка изучение программирование что бы потом начать учить ООП + Java? та Вы прикалываетесь.....

  • Fail review: о проблемах в разработке и методах их решения

    Так может не стоит в своем функционале полагаться на зависимость зависимости зависимости?)
    Я не вижу, чтобы кто-то полагался на зависимость зависимость.
    Формат даты не передается параметром. Сразу писать свой виджет? Нафиг сторонние либы, мы лучше набросаем?

    Про второй уровень зависимости важно потому, что если б сам компонент «не предусматривал» — то сделать пулл-реквест, обоносвать и обновить зависимость — еще реально.
    А вот, если надо в несколько проектов пулл-реквесты пихать, то да, проще на лету что-то у себя менять.

    Впрочем, можно и все зависимости форкать, но замахаешься этим потом рулить.

  • DevOps дайджест #12: сравнение оркестраторов, микросервисы на Go и что у Uber под капотом

    По поводу даунтайма на s3 можно так же настроить амазоновский CDN на свой бакет s3 что бы решить задачу

  • В ночь с пятницы на воскресенье, или Затертые изменения

    Абсолютно верно

    тщательный отбор персонала, основанный на общих ценностях
    Касательно категоричности заявления скажу, что описанная ситуация и решения вызвали некое удивление :)
  • Fail review: о проблемах в разработке и методах их решения

    Так может не стоит в своем функционале полагаться на зависимость зависимости зависимости?)

  • В ночь с пятницы на воскресенье, или Затертые изменения

    то есть, в первую очередь — тщательный отбор персонала, основанный на общих ценностях. Верно?
    А то у меня претензия не к пулл-реквестам как механизму(тоже используем), а только к категоричности заявления, будто механизм или процесс легко исправить корявую коммуникацию.

  • Fail review: о проблемах в разработке и методах их решения

    Ах да, это же такую js-библиотеку использовали.
    нет.
    которая имеет третий уровень вложенности
    это значит «мы используем такую-то либу, которая в свою очередь использует такую-то либу».
    Соответственно, просто так заменить А на В не выйдет.
  • Fail review: о проблемах в разработке и методах их решения

    Последняя история (про даты) — ну это ж вообще, как можно было с самого начала не предусмотреть такую простую вещь. Ах да, это же такую js-библиотеку использовали.

← Сtrl 12345678910 Ctrl →