• Базовые различия при работе с базами данными MySQL и PostgreSQL Дилетантский обзор

      Продолжая свое знакомство с БД PostgreSQL, с уже имеющимися навыками работы в БД MySQL, обнаружил ряд интересных полезных особенностей которые на практике часто не хватало в MySQL. Цель этого обзора не в создании бесконечного спора, что лучше, а дать легкое сравнение, которое обычно обсуждается программистами на обеденном перерыве в ближайшей кафешке. В сравнении обретаются новые знания и опыт, поэтому оно того стоит.
      Читать дальше →
      • +10
      • 14,5k
      • 8
    • Установка связки Carbon + Graphite + Grafana + Nginx + MySQL для сбора и отображения метрик в Ubuntu

      • Tutorial

      Хочу поделиться опытом установки и настройки сервиса для сбора и отображения метрик Graphite + Grafana.
      Искал долго, читал много, нашёл 2 статьи на английском, добавил своё, в итоге получилась данная статья.


      Немного предыстории..


      Graphite — система для отображения метрик (числовых значений) для любых свойств сервера или домашнего ПК.


      Carbon — демон/бэкенд, в который пишутся метрики.


      Grafana — более красивая и удобная Web-морда для Graphite.


      И так, приступим.

      Читать дальше →
    • Различие работы в использовании индексов в условии 'OR' баз данных Mysql и PostgeSQL

      Многим известна проблема MySQL в не использовании индексов для двух индексируемых колонок в условии «OR». Если подробнее, в таблице есть несколько колонок с проставленными по ним индексами и затем делается выборка по этим колонкам с использованием условия «OR». Индексы не работают. Я решил исследовать этот момент в сравнении с PostgreSQL, так как в настоящий момент времени поставил для себя цель немного познакомиться в PostgreSQL.
      Читать дальше →
    • PostgreSQL — не Rocket Science. Почем сейчас яйца?



        Постоянно натыкаюсь на высказывания из серии «PostgreSQL слишком сложная база для моего небольшого проекта, поэтому буду продолжать работать с MySQL».
        В этой статье я хотел бы показать, что человеку, знающему MySQL, не составит абсолютно никакого труда начать разрабатывать под PostgreSQL
        Читать дальше →
      • Чем PostgreSQL лучше других SQL баз данных с открытым исходным кодом. Часть 2

        • Перевод
        Друзья, представляем вашему вниманию вторую часть перевода «Чем PostgreSQL лучше?». Надеемся, она вызовет такое же горячее обсуждение в комментариях, как и первая часть. А также с радостью продолжим с вами дискуссию лично на PG Day'16 Russia, до которой осталось совсем немного!

        В слогане PostgreSQL заявляется, что это «Самая продвинутая база данных с открытым исходным кодом в мире». В первой части этой серии мы рассмотрели хранение данных — модель, структуры, типы и ограничения по размеру, — чтобы дать вам несколько причин, почему Постгрес подтверждает свои слова делом. Во второй части мы поговорим о манипуляциях с данными и поиске, включая индексирование, виртуальных таблицах и возможностях запросов. В этой серии мы выясняем, что выгодно отличает PostgreSQL от других баз данных с открытым исходным кодом, а именно — от MySQL, MariaDB и Firebird.


        Читать дальше →
      • Статистика распределения доменов по AS, IP, NS, MX и прочим параметрам

          Давным-давно перестал работать 1stat.ru — откровенно говоря, для нас это была трагедия (сейчас вроде он как-то работает).

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


          Подробности
        • DevConf::Storage — отдай голос за свою любимую базу данных до 31 мая

            Большая конкуренция наблюдается за выбор базы данных в секции Storage программы DevConf 2016 — должны остаться только лучшие и интересные доклады.

            Голосование продлится до 31 мая, сформируем программу вместе!

            Представляем вашему вниманию 11 кандидатов на участие:

            Крылья, ноги и хвосты: сильные стороны MySQL и когда PostgreSQL завоюет мир
            Алексей Копытов
            В наш гибридный век как разработчикам, так и администраторам часто приходится иметь дело со многими разными СУБД. Знание сильных и слабых сторон каждого продукта становится всё более важным навыком, но информация по этим вопросам, которую можно найти в сети, имеет целый ряд проблем: быстрая потеря актуальности в связи с постоянным и быстрым развитием популярных СУБД, разрозненность, а также предвзятость и зачастую некомпетентность авторов.

            Мастер-мастер репликация в Tarantool
            Konstantin Osipov
            Расскажу как устроена и как пользоваться мастер-мастер репликацией в Tarantool:
            • инициализация кластера
            • добавление и удаление узлов
            • разрешение конфликтов
            • восстановление после аварии
            • мониторинг состояния.
            Вместе посмотрим на производительность.
            Читать дальше →
          • AdBlock похитил этот баннер, но баннеры не зубы — отрастут

            Подробнее
            Реклама
          • MySQL – это лучшая NoSQL-система

              При рассмотрении сценариев использования NoSQL, таких как хранение пар ключ-значение, оказывается, что MySQL более предпочтительна с точки зрения производительности, легкости использования и стабильности. MySQL – это основательная система с обилием онлайн-материалов, которые охватывают все темы от основных операций и разбора ошибок до репликации и различных паттернов использования. Это дает MySQL преимущество перед более молодыми NoSQL-системами, у которых нет такого опыта.

              За последние годы NoSQL-системы стали господствующим направлением. Многие разработчики видят в NoSQL-системах, таких как MongoDB, Cassandra, Redis или Hadoop, оптимальный вариант для построения своих приложений, считая их единой семьей продуктов, которая обесценивает старые SQL-системы.

              Зачастую, в основе решения об использовании базы данных NoSQL лежит рекламная шумиха или ошибочное убеждение, что реляционные базы данных не могут обеспечить такую же производительность, как базы данных NoSQL. Когда доходит до выбора базы данных, инженеры часто упускают из виду эксплуатационные расходы, а также соображения стабильности и зрелости технологии. Чтобы узнать больше об ограничениях и изъянах различных NoSQL (а также SQL) систем, обратите внимание на серию статей проекта Jepsen, опубликованную на Aphyr.com.

              В этой статье мы объясним, почему, по нашему мнению, использовать MySQL для хранения пар ключ-значение лучше, чем большинство специализированных NoSQL-систем, а также предоставим инструкции для использования MySQL.
              Читать дальше →
            • Заметки о Percona Live 2016 CA

                Недавно я побывал на замечательной конференции Percona Live 2016 в Санта-Кларе. Хочется написать множество хвалебных слов организаторам и за отлично работающий Wi-Fi, и питание, и точное следование расписанию, и подготовку залов. Но все же статью я пишу не для туристического сайта, а для технического, потому просто расскажу о самых интересных докладах из тех, которые я посетил.

                На удивление для столь узкоориентированной конференции, спектр докладов не ограничился одним только MySQL, как это могло бы показаться, но охватывал в целом инструменты работы с данными. Место нашлось и Hadoop с экосистемой и колоночными базам данных, и облакам (куда сейчас без них).
                Читать дальше →
              • Работа с MySQL: как масштабировать хранилище данных в 20 раз за три недели

                • Перевод


                Ранее в блоге на Хабре мы рассказывали о развитии нашего продукта — биллинга для операторов связи «Гидра», а также рассматривали вопросы работы с инфраструктурой и использования новых технологий. К примеру, мы рассмотрели плюсы Clojure, ситуации, когда стоит и не стоит использовать MongoDB и ограничения в PostgreSQL.

                Сегодня речь пойдет о масштабировании. Разработчики open-source почтового приложения Nylas опубликовали в своем блоге материал о том, как им удалось масштабировать систему в 20 раз за три недели с помощью инструмента ProxySQL. Для этого им пришлось переехать с Amazon RDS на MySQL на EC2. Мы представляем вашему вниманию основные моменты этой интересной заметки.
                Читать дальше →
                • +11
                • 29,4k
                • 6
              • Чем PostgreSQL лучше других SQL баз данных с открытым исходным кодом. Часть 1

                • Перевод
                Сегодня давайте поговорим о преимуществах Postgres перед другими системами с открытым кодом. Эту тему мы обязательно раскроем более подробно на PG Day'16 Russia, до которой осталось всего два месяца.

                Возможно, вы спрашиваете себя: «Почему PostgreSQL?» Ведь есть и другие варианты реляционных баз данных с открытым исходным кодом (в рамках этой статьи мы рассматривали MySQL, MariaDB и Firebird), так что же Постгрес может предложить такого, чего нет у них? В слогане PostgreSQL заявляется, что это «Самая продвинутая база данных с открытым исходным кодом в мире». Мы приведем несколько причин, почему Постгрес делает такие заявления.

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


                Читать дальше →
              • Очередная Reflection Library и ORM для C++



                Сразу же предупрежу о велосипедности выдаемого здесь на обозрение. Если прочтение заголовка вызывает лишь с трудом подавляемый возглас «Твою мать, только не новый таксон ORM!», то лучше наверное воздержаться от дальнейшего чтения, дабы не повышать уровень агрессии в космологическом бульоне, в котором мы плаваем. Виной появлению данной статьи явилось то, что в кои-то веки выдался у меня отпуск, в течение которого решил я попробовать себя на поприще написания блогопостов по околохабровской тематике, и предлагаемая тема мне показалась вполне для этого подходящей. Кроме того, здесь я надесь получить конструктивную критику, и возможно понять чего же еще с этим можно сделать этакого интересного. В конце будет ссылка на github-репозиторий, в котором можно посмотреть код.
                Читать дальше →
              • Отчёт с Percona Live 2016: чего ждать от MySQL 8?


                  Привет, Хабр! На прошлой неделе прошла конференция Percona Live Data Performance Conference 2016. Как обычно, тонны новой информации, и я всё ещё разбираю свои заметки и пролистываю слайды докладов, на которые попасть не удалось. Сообщество MySQL открыто и дружественно относится к «параллельным» сообществам и проектам. Естественно, были доклады об Oracle MySQL, MariaDB и Percona Server, но были также доклады и о MongoDB, Redis, Tarantool, Hadoop, Cassandra, Scylla, Ignite, HBase, ActorDB, SQLite, ToroDB, Tempesta DB и даже доклад об оптимизации PostgreSQL, несколько обобщённый для MySQL и других СУБД.


                  Сотрудники Oracle делились планами о MySQL 8 неожиданно щедро как в докладах, так и в кулуарах. Мне эта информация показалась достаточно интересной, поэтому я решил составить краткую сводку из услышанного.


                  Читать дальше →
                • VoIP Часть 1

                  Признайтесь, было ли у Вас когда-нибудь желание послушать, о чем говорят друзья, жены, мужья и т.д. без Вас? Было бы классно набрать телефонный номер, и чтобы связь сама устанавливалась и не ждать, когда пользователь ответит на звонок. Я уже активно пользуюсь этим функционалом и это, скажу Вам, затягивает. Реализовывая его в рамках одного мобильного приложения, я долго искал готовые решения, но, конечно же, ничего не нашел. В итоге за 2 вечера (6 часов), мне удалось реализовать эту задачу. Но обо всем по порядку…

                  Читать дальше →
                • Управление структурой базы данных без боли

                  image

                  Хочу поделиться инструментом, который родился при разработке одного веб-проекта и очень помогает мне не потеряться в море таблиц, хранимых процедур, индексов и прочих обитателей базы данных.

                  Сам проект написан на Django, в качестве бекенда — PostgreSQL. В самом начале работы было решено, по крайней мере, частично отказаться от использования Django ORM в пользу «сырого» SQL и хранимых процедур. Другими словами, почти вся бизнес-логика вынесена на уровень базы данных. Сразу скажу, что готовить ORM я умею, но в данном случае требовалось производить многоступенчатые вычисления, связанные с множеством выборок, а это лучше делать на сервере БД и не таскать промежуточные данные в приложение.

                  Столкнувшись с необходимостью поддержания структуры базы данных вручную, без приятностей Django Migrations, я выяснил, что вручную писать инкрементальные SQL патчи возможно, но трудно уследить за зависимостями объектов БД. К примеру, когда функции, которая используется где-то еще, добавляешь еще один аргумент, простого CREATE OR REPLACE недостаточно — ее нужно сначала DROP, а потом CREATE. При этом нужно предварительно удалить зависимые от нее функции, а потом создать заново (а если от этих функций еще кто-то зависит, тогда надо и их пересоздать).

                  Под катом краткое описание возможностей в виде туториала. Встречайте — Sqlibrist.
                  Читать дальше →
                • Масштабируя до 100 миллионов: архитектура, определяемая уровнем сервиса

                    Это третья часть цикла «Масштабирование Wix до 100 миллионов пользователей». Вступление и второй пост.

                    Wix начинался с одного сервера, который обеспечивал весь функционал: регистрацию пользователей, редактирование веб-сайтов, обслуживание опубликованных веб-сайтов и загрузку изображений. В свое время этот единственный сервер был правильным решением, поскольку он позволил нам быстро расти и применять гибкие методы разработки. Однако к 2008 году начались периодически повторяющиеся проблемы с развертыванием, которые вели к незапланированным простоям как в создании новых сайтов, так и в обслуживании уже созданных.

                    Развертывание новой версии нашей системы в некоторых случаях требовало изменения схемы MySQL. Поскольку Hibernate не прощает несовпадений между ожидаемой им схемой и реальной схемой базы данных (БД), мы использовали общую практику развертывания программного обеспечения: плановая двухчасовая остановка в период наименьшего трафика (полночь в США на выходных). За время этой плановой остановки мы должны были остановить сервис, выключить сервер, внести изменения в схему MySQL, развернуть новую версию и перезапустить сервер.

                    Эта плановая двухчасовая остановка часто превращалась в нечто более сложное из-за проблем, которые могли случаться при развертывании. В некоторых случаях внесение изменений в схему MySQL занимало заметно больше времени, чем планировалось (изменение больших таблиц, перестройка индексов, отмена ограничений на миграцию данных и т.д.). Иногда после изменения схемы и попытки перезапустить сервер он не запускался из-за каких-то непредусмотренных проблем с развертыванием, конфигурацией или схемой, которые не давали ему работать. А в некоторых случаях новая версия нашего программного обеспечения оказывалась неработоспособной, поэтому для восстановления сервиса нам приходилось снова менять схему MySQL (чтобы привести ее в соответствие с предыдущей версией) и вновь разворачивать предыдущую версию системы.
                    Читать дальше →
                  • Масштабирование до 100 миллионов пользователей. Кэшировать или не кэшировать?

                      Это вторая часть цикла «Масштабирование Wix до 100 миллионов пользователей». Вступление читайте тут.

                      Когда мы только запускали Wix, был использован стек Tomcat, Hibernate и Ehcache c базой данных MySQL и фронтендом на Flash. Почему мы выбрали этот стек? Да просто потому, что у нашего первого бэкенд-разработчика уже был опыт работы с ним. Частью этой архитектуры был Ehcache – отличная кэш-библиотека для Hibernate и JVM, которая создавала абстракцию в виде карты для кэша памяти и которая могла также быть сконфигурирована как распределенный кэш. Ehcache, в отличие от Memcached, запускается как процесс в JVM и в точности реплицирует состояние кэша для всех узлов кластера. Обратим внимание, что в то время (около 2006–2008 гг.) Encache все еще был независимым open source проектом и не был частью Terracotta (в рамках Terracotta модель репликации и дистрибуции может быть иной, но для данной статьи это не столь важно).

                      Аспекты использования кэша




                      Поскольку у нас уже были реальные клиенты, мы установили два сервера Tomcat для обеспечения дополнительной надежности. Следуя правилам выстраивания архитектуры, мы установили распределенный Ehcache-кластер между серверами. Мы исходили из того, что MySQL работает медленно (как и любая другая SQL-система), а значит кэш оперативной памяти обеспечит гораздо более высокую скорость чтения и снизит нагрузку на базу данных.
                      Читать дальше →
                    • Визуализация инструментов обработки данных с Github

                        В своей работе вы используете MySQL, Postgres или Mongo, а может даже Apache Spark? Хотите знать с чего начинались эти проекты и куда они движутся сейчас? В этой статье я представлю соответствующую визуализацию



                        Читать дальше

                      Самое читаемое