MySQL *

Foglight for Databases — удобный инструмент для DBA, который поддерживает мониторинг SQL Server, Oracle, MySQL, PostgreSQL, DB2, SAP ASE, MongoDB и Cassandra. И всё это в одном интерфейсе.

Кроме этого, инструмент позволяет сравнивать производительности БД в разные периоды времени (например, до релиза и после него), а также выполнять сравнение производительности различных экземпляров.



Приглашаем вас зарегистрироваться на вебинар, который состоится 7 апреля в 11 часов по московскому времени. Вы узнаете о возможностях решения, кейсах использования, лицензировании и сможете задать интересующие вопросы. Если вы не сможете присутствовать на вебинаре, в любом случае оставьте ваши контактные данные, мы вышлем вам запись после мероприятия. Под катом описание функционала решения и несколько скриншотов.

Перевод статьи подготовлен в преддверии старта курса «Backend-разработчик на PHP».

---

Привет! Я Валерио, разработчик из Италии и технический директор платформы Inspector.dev.

В этой статье я поделюсь набором стратегий оптимизации ORM, которые я использую, разрабатывая сервисы для бэкенда.

Уверен, каждому из нас приходилось жаловаться, что сервер или приложение работает медленно (а то и вовсе не работает), и коротать время у кофемашины в ожидании результатов длительного запроса.

Как это исправить?
Давайте узнаем!

Сейчас в глазах обычной публики машинное обучение прочно ассоциируется с различными вариантами обучения нейронных сетей. Если первоначально это были полносвязные сети, потом заместившиеся сверточными и рекуррентными, то теперь это стало совсем экзотическими вариантами типа GAN и LTSM-сетей. Кроме все больших объемов выборок, требуемых для их обучения, они еще страдают невозможностью объяснить, почему было принято то или иное решение. Но существуют и структурные подходы к машинному обучению, программная реализация одного из которых описана в настоящей статье.

Привет, Хабр!

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

Всем привет. В преддверии старта курса «Fullstack разработчик JavaScript», хотим поделиться небольшим материалом, который был написан нашим внештатным автором.



Express один из самых популярных веб-фреймворков, который поддерживает роутинг, миддлвейрс и систему шаблонов. Делать бэкенд на Node.js без Express в 2020 году — довольно странное занятие, ведь Express де-факто — каркас для создания веб-приложения на Node.js.
Сегодня мы попробуем создать несложное CRUD API используя базу данных MySQL. Опытный в Node.js читатель спросит, а где же MongoDB, с которым Node.js обычно применятся в паре но, скажу сразу, это статья больше для PHP разработчиков, которые хотят немного потрогать Node.js, и чтобы смягчить переход в новую экосистему мы воспользуемся MySQL. API мы будем создавать для несложного Todo приложения, на тот случай, если кто-то захочет к своей todo (и даже неважно, написанной с помощью React или нет), присоединить немного бэка и поиграть с ним.

Здравствуйте, Хабр.

Сегодня мы предлагаем вашему вниманию перевод статьи из блога MemSQL, которая исходно является рекламной (посвящена достоинствам MemSQL, обновлена по состоянию на начало января 2020 года). Но мы решили все-таки перевести ее в сокращенном виде, поскольку она подробно объясняет, почему мы пока так и не собрались издавать ничего ни по MongoDB, ни по Cassandra, ни по прочим нереляционным базам данных. Может быть, мы были правы, ограничившись весьма успешной книгой "MySQL по максимуму".

Предыстория

Есть небольшой сервер, на котором крутится стандартный LAMP. Все началось с того, что подходит ко мне QA и говорит: «Есть тема, мне нужно перепроверить регистрацию пользователей, можешь удалить старый аккаунт?», «Не вопрос» — ответил я. Суть в том, вход у нас сделан только через социалки. Что бы не нарушать целостность базы удалением аккаунта, я решил просто взять и переименовать UID (пользовательский ID в конкретной социальной сети) в таблице.
Так как UID у всех разный (vk, facebook, google… — числовой UID, linkedin — строковый UID) был использован VARCHAR для хранения. В итоге я добавил символ нижнего подчеркивания `_` к строке, и со спокойной душой отписался: «Проверяй...».

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

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

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

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

Давным-давно (кажется, в прошлую среду) попался ко мне в руки дамп базы данных MySQL, который следовало немедленно развернуть на моей машине. Зачем это было нужно и откуда взялся дамп, рассказывать не буду, вряд ли это кому-то интересно. Важно то, что дамп был от MySQL 4.1.22 и снят он был при помощи одного широко известного инструмента (версии 5.23).
Разворачиваться у меня он решительно отказался... 
 

Лучше совсем не помышлять об отыскании каких бы то ни было истин, чем делать это без всякого метода. (Рене Декарт)

Разработчику баз данных очень часто приходится иметь дело с древовидными структурами. Все в этом мире является частью одной или многих иерархий и поэтому умение эффективно хранить и управлять данными такого рода является очень важной задачей.

Существует много методов от самых примитивных до очень сложных и возможно слишком сложных. Мы не будем описывать их в этой статье. При желании вы можете найти множество прекрасных обзорных статей в интернете “Google forever”.

Мы представляем на суд разработчиков метод Cartesius который основан на представлении иерархической структуры на координатной плоскости где каждый узел имеет свою координату в виде двух параметров ord и dep.

Большинство компаний сейчас имеют IP-телефонию, построенную на базе Asterisk(*). Недавно столкнулся со следующей, на первый взгляд, банальной задачей: имеется около 50 человек сотрудников, у каждого из них есть внутренний (добавочный) номер и корпоративный рабочий. Надо чтобы сотрудник был постоянно на связи, так как в офисе не все и не всегда находятся, а если не дозвониться клиент — будет беда. Первое, что приходит в голову — диалплан следующего вида:

exten => 3333,1,Dial(SIP/${EXTEN},20,tT); вызываем добавочный
exten => 3333,2,Dial(SIP/trunk/3809631234567,60,tT); если не ответ — набираем на мобильный.

Вроде все просто и красиво. НО! Это мы описали только одного сотрудника, а их 50! А еще надо каждый разговор записать, например. Листинг уже разрастается до неприличных масштабов. И не только листинг, но и количество ошибок, что можно наделать в процессе составления диалплана. Первое, что мне пришло в голову — старый, добрый MySQL. Что мы можем тут реализовать? Все просто, забиваем базу сотрудников с их добавочными и мобильными номерами и, подставляя их в переменные, звоним.

Добрый день.

Некоторое время назад проект нашей компании по мониторингу серверов и сайтов перешел из категории «сделано для себя» в плоскость привлечения массовых пользователей. Этому частично способствовало получение проектом посевных инвестиций от ФРИИ и плюс, конечно же, наличие желания поделиться с миром нашей технологией, которую мы также используем для мониторинга своих серверов. Но, это не рекламный пост, а практический, поэтому о проекте потом.

Итак, с ростом нагрузки на базу данных, а наш сервис — это SaaS платформа по сбору метрик с серверов, количество запросов на запись в нашу базу данных (сейчас более 1000 серверов посылают порядка 20 своих метрик в БД каждые 4 минуты) начало приводить к перегрузке БД и нестабильной работе сервиса. Это зачастую происходило из-за превышения установленного максимального количества соединений к MySQL и большой нагрузки на сервер. К сожалению, все попытки оптимизации MySQL, увеличения серверных ресурсов и настройки параметров max_connections, query cache и т.д. не приводили к успеху.

Т.к. у нас нет отдельного человека, отвечающего за базы данных, а программисты и системные администраторы не могут каждый день тратить кучу времени на поддержание стабильности MySQL и реагировать на каждое падение, мы решили перейти на MariaDB Galera кластер с master-master репликацией и балансировкой нагрузки с помощью HaProxy. У нас до этого не было опыта внедрения бд кластера в production environment и поэтому пришлось наступать на все грабли самостоятельно.

К счастью, на Хабре нашлось много полезных статей на тему настройки Percona XtraDB, HaProxy и Zabbix для Percona, а также серия статей «Идеальный Кластер», которые нам очень помогли в начальной установке.

Здравствуй, Хабрахабр! Меня зовут Бабичев Максим. Это моя первая статья на Хабрахабр, прошу строго не судить.

Нашел на Хабре статью, в которой были базы в двух модификациях: Страны и города и только страны. Также в этих архивах есть небольшие примеры использования таблиц на php.

Сразу хочу сказать, что эта статья рассчитана на новичков, а не на продвинутых гуру.

Я хочу поделиться со всеми читателями интересной темой, с которой столкнулся совсем недавно, и мне она понравилась. Развитие этой темы доставило мне удовольствие и добавило немного опыта в копилку. Вероятно, многие, а может и нет, сталкивались с пулом соединений БД. После ознакомления с этой интересной опцией мне захотелось написать статью и поделиться ею с вами. Возможно, статья получится немного длинной, но я думаю, что данный пост кому-то все же будет интересно почитать, и его заинтересует данная тема. Может быть наработки с этой статьи кто-то использует в своем проекте, в любом случае, мне будет интересно ее писать и рассказывать ее вам.

Есть немало книг, описывающих особенности и специфику конкретных БД.
Значительно меньше «программно-независимых» изданий, которые рассказывают об общих правилах и законах проектирования баз, принципах построения, нарушение которых может привести в дальнейшем к серьёзным ошибкам и проблемам. Где рассмотрена вся методологическая цепочка от постановки задачи до итогового анализа уровня целостности данных для каждого приложения.

Мы сейчас обсуждаем возможность издать на русском языке книгу Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design и хотели бы включить в эту дискуссию «коллективный разум».

Уважаемые читатели! Пожалуйста, оцените это издание по пятибалльной шкале. Насколько оно раскрывает тему? Будет ли оно полезно разработчикам БД — лично вам, или, может быть, вашим менее опытным коллегам, которые смогут избежать ошибок проектирования?
Комментарии своей оценки, как всегда, приветствуются.

2го августа, в пятницу, состоится очередная встреча Moscow MySQL User Group.

Встреча состоится в офисе Yandex, для участия необходима регистрация.

У нас будет два доклада от Percona, от Алексея Копытова и Николая Ихалайнена, а также некоторое количество книг от Oracle Press.

Анонс на сайте Яндекса и регистрация:
events.yandex.ru/events/yagosti/MMUG

Введение

Здравствуй, $habrauser!

Бывает так, что вам нужно импортировать файл Excel в базу MySQL, но готового решения нигде нет. Вот и я, когда меня попросил друг поискать легкий способ импорта, сперва решил загуглить поискать решение. Увы, запрос php excel to mysql не дал ничего конкретного, или же описанные способы были довольно таки не удобны. Тогда же я решил найти библиотеку для работы с Excel на PHP, и мне попалась PHPExcel. Но опять же меня ждало разочарование, запрос phpexcel to mysql не дал ничего путного (я ленивый пользователь и дальше 1й страницы не хожу). В итоге я решил создать свой велосипед скрипт, которым и хочу поделиться с вами.

Почта в своей конторе разрослась и наличие более чем 1 рабочего места у более чем 1 сотрудника начали требовать большего, нежели простейшая реализация мультидоменного почтового сервера на базе exim+teapop без использования mysql на обычных файликах. Главная причина изменений — постоянное вычищение спама и просто ненужных писем на каждом из рабочих мест по многу раз начало доставать, и было принято решение реализовать-таки почту по известной статье лиссяры "Связка exim и courier-imap". Самое главное, чего в ней не хватало из того, что требовалось, так это сортировщика писем по папкам. Для того, кто подписан на рассылки, весьма полезно раскладывать письма по требуемым каталогам, чтобы: а) не писать сортировщики в каждом клиенте; б) иметь такую же структуру папок при доступе к почте через веб, как и в почтовом клиенте.