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

    Вот пожалуйста Оракл пишет

    B-trees, short for balanced trees, are the most common type of database index. A B-tree index is an ordered list of values divided into ranges. By associating a key with a row or range of rows, B-trees provide excellent retrieval performance for a wide range of queries, including exact match and range searches.

    По поводу аналитики лол. Мы используем Spark и Druid, а также сервисы Azure.

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

    В Facebook подсказали хорошую статью по теме

    PACELC. The lack of the CAP Theorem is addressed in an article by Daniel Abadi in which he points out that the CAP Theorem fails to capture the trade-off between latency and consistency during normal operation, even though it has proven to be much more influential on the design of distributed systems than the availability-consistency trade-off in failure scenarios. He formulates PACELC which unifies both trade-offs and thus portrays the design space of distributed systems more accurately. From PACELC, we learn that in case of a Partition, there is an Availability-Consistency trade-off; Else, i.e. in normal operation, there is a Latency-Consistency trade-off.

    Какое хранилище выбрать? — Диаграма

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

    соглашусь, что я перебрал в разделе с базами так как я не знаю все нюансы реализации конректного движка.
    Sql баз много разных и много версий существует. В разных версиях реализация базы отличается. Я рад что сейчас есть куча оптимизаций в виде write ahead и так далее.
    Но у всех баз как раз общее — это b-tree и реляционная алгебра. Насколько я знаю все sql базы начинались с 1-3NF и b-tree. R-tree, hash, heap — все это не относится к реляционной теории.

    По поводу перестроения индексов — действительно, не все сразу пишется на диск, здесь я ошибся. Но вы же не будете отрицать что чем больше индексов тем медленее запись? Индексы перестраиваются синхронно и это может потребовать загрузить страницы с диска — чтобы сделать изменение надо страницу прочитать сначала.
    Мы же говорим про сферического коня в вакууме. Если у вас вся база в памяти помещаться — оптимизаторы хорошо сработают и IO почти не будет. Но как правило ваша база в 10+ раз больше чем памяти, и здесь IO начинает играть важную роль.

    Я думаю поправить абзац про sql. Будет супер если вы посоветуете что конкретно туда написать.

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

    Нет не знаю, я не эксперт в Data Warehouse. Расскажите, очень интересно.

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

    Слив засчитан

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

    Ну так напишите альтернативную точку зрения. Я смотрю вы часто создаете в базе кучи и r-tree, расскажите нам об этом, очень интересно. Расскажите нам как часто вы создаете таблицы без индексов и для каких целей, заранее спасибо

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

    в книжці, на котру ви посилаєтесь, кажуть, що шардніг і реплікейшн вирішують цю проблему, а eventual consistency — це вже як наслідок.
    Все правильно, они решают проблему. Но сделать шардинг и партишенинг на Оракле или SQL Server вам будет стоить очень дорого — enterprise лицензии и все такое.
  • Not Only SQL: ищем альтернативы реляционным базам

    В Azure Table Storage нет Secondary Indexes, я раньше думал это проблема, но теперь я придерживаюсь мнения что это хорошо что так сделали by design. Если нужны индексы — у МС есть Azure DocumentDb, которая очень близка к MongoDb

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

    Или обновление одного источника, если произошло изменение второго источника.

    Для этого удобны очереди — можно изменять второй источник в один поток, или в несколько по желанию

    А как вы решаете задачи, которые просто реализуются реляционными СУБД? Например запрос, связывающий несколько источников данных по некоторому условию?
    Ну задачи уровня — сделать запрос из нескольких источников данных можно решать по разному. Несколько источников данных на практике это несколько разных апи отдающие json или xml. Скорее всего это разные сервисы и они не могут быть полностью согласоваными (strict consistency). Мне кажется в зависимости от сложности и характера запросов лучше использовать документную базу или решения типа Spark
  • Почему я не использую реляционные СУБД

    Сейчас модно строить высоконагруженные системы при помощи Event Sourcing, а данные хранить в клауде. Проблема тех кто знает сиквел что для них весь мир состоит из реляционных данных в третьей нормальной форме, но это конечно же не так. Вы когда идете в магазин и покупаете товар, врядли продавец думает что ваша покупка должна быть транзакционной и что кило картошки как-то связанно с покупателем

  • Почему я не использую реляционные СУБД

    Автор молодец, а по «лучшим» комментам виден «аутсорсинг головного мозга».

    Я уже на энном проекте с сиквелом работаю и меня от него тошнит. Типичный «субд» выглядит так — берем любой сиквел (лучше какойнить энтерпрайз эдишн по 10 килобаксов за ядро), напихиваем туда данных побольше — все что у нас есть, пишем кучу stored procedures, храним конфигурацию всех сервисов, создаем табличку со списком валют и стран, а также языков и часовых поясов (а то вдруг надо будет новый часовой пояс добавить!), обязательно должна быть табличка с логами (лучше отдельная база!), конечно же все делаем в третьей нормальной форме (а-ля табличка PaymentType с тремя записями {1, Paypal}, {2, Card}, {3, Cash} которую надо потом джойнить во все запросы), потом реализовываем очередь чего-либо на базе таблицы, потом создаем кучу вьюх, индексов, триггеров, репортов — и побольше всего. Ведь в сиквеле столько фич — он может все! Ах да, я же забыл полнотекстовый поиск и запросы из столбца типа XML... Потом надо обязательно настроить миллиард кривых пермишенов и для полноты картины настоить репликацию и зеркало.

    Мне очень жаль что для многих сиквел — это единственная технология которую они знают. Пора открыть глаза и понять что сиквел и б-деревья — это одно из десятков существующих решений для хранения и работы с данными. Людям с тайтлом «архитектор» я бы вообще порекомендовал воздержаться от комментариев в теме чтобы не позорить свой тайтл...

  • Беседа с Дарьей Назаркиной, HR консультантом

    Ну чего? Как вы поплавали?..

  • Mercurial vs. Git в коммерческой разработке

    Зашивать номер таски в бранч? А что если опечатался? =)

    Я думал уже все перешли на Continuous Integration и пишут код в одной ветке под названием dev.

    Я пользовался обоими системами и могу сказать что разница невелика, но Гит лучше =) Просто в Гите все продумано, поєтому и бранчи там нормальніе. А Меркуриал віглядит как неудачній клон Гита — все віглядит похоже, но что-то недоделано в нем...

    Підтримали: Ivan Sorochan, Vanya Yani
  • 10 лет ДОУ

    Макс, я когда в своем браузере ввожу букву d — у меня dou.ua на первом месте в списке подсказок. Я считаю это win! =)

  • Логи как лучшее средство от дебага

    Да, логи это конечно нужно и хорошо, но когда у вас сложная система и много серверов — логи не спасают. Нужны инструменты другого уровня, например Kibana www.elasticsearch.org/...verview/kibana

    Пример использования: i57.tinypic.com/2e578sn.jpg

  • Предложение новому кабмину о 3g связи

    Зачем мне тримоб если я хочу чтобы полноценная 3g связь была у всех основных операторов — Киевстар, МТС, Life...

  • Предложение новому кабмину о 3g связи

    Макс, если ты создашь такую страничку — я тебе буду очень благодарен. Ты уважаемый человек и тебя знают многие. А соответственно твои инициативы потенциально имеют бОльшую поддержку, чем у просто смертного =)

  • Предложение новому кабмину о 3g связи

    4g Дороже. Любой кто был забугром и пользовался 3g подтвердит что между 3g и EDGE который предлагают у нас по дефолту — пропасть в скорость и комфорте использования.

← Сtrl 1... 456789 Ctrl →