SQL *

Создание и поддержка в одиночку сложного продукта с большим зоопарком технологий и без финансовых вливаний со стороны — дело хлопотное и утомительное. Поэтому, узнав про конкурс с интересной задачей, мы в Мегаленте я подумал о том, чтобы устроить себе "творческий отпуск" и отвлечься ненадолго от работы над новой версией.

Задача состояла в том, чтобы написать программу на JS, которая будет определять, есть слово с словаре английских слов или нет. Вроде бы просто, но есть пара ограничений, делающих задачу заведомо невыполнимой:
– Словом считается не просто любое правильное слово английского языка, а именно слово, которое есть в предоставленном словаре из 600K+ слов.
– Словаря в момент исполнения программы нет, скачать его нельзя, а размер программы, включая данные, не должен превышать 64К. Внешние библиотеки подключать также нельзя, но файл данных может быть заархивирован.
Благодаря этим условиям вместо однозначного ответа результатом может быть только определение наибольшей вероятности присутствия слова в словаре.

Сразу скажу, что решение я так и не отправил из-за неудовлетворённостью результатом (решение, которое давало хотя бы 80%, я смог поместить только в 120-130К, а без превышения размера в 64К выжал максимум 70%).
Тем не менее опыт считаю достаточно интересным и достойным статьи. Под катом много SQL,JS,Python, нейронные сети, а также печальная правда о производительности CPU на хостинге.

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

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

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

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

Мастер-мастер репликация в Tarantool
Konstantin Osipov
Расскажу как устроена и как пользоваться мастер-мастер репликацией в Tarantool:

• инициализация кластера
• добавление и удаление узлов
• разрешение конфликтов
• восстановление после аварии
• мониторинг состояния.

Вместе посмотрим на производительность.

В этой небольшой заметке будет показано, как написать DataGrip расширение для генерации кода (в данном случае POCO (C#) классов) на основе таблиц из почти любой БД (SQL Server, Oracle, DB2, Sybase, MySQL, PostgreSQL, SQLite, Apache Derby, HyperSQL, H2).

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

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

Перейдем к конкретной «ходовой» задаче — объектная прослойка для работы с базами данных в PHP. Решений великое множество, начиная от PDO и заканчивая многоуровневыми (и, на мой взгляд, не совсем уместными в PHP) ORM движками.

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

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

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

Сразу же предупрежу о велосипедности выдаемого здесь на обозрение. Если прочтение заголовка вызывает лишь с трудом подавляемый возглас «Твою мать, только не новый таксон ORM!», то лучше наверное воздержаться от дальнейшего чтения, дабы не повышать уровень агрессии в космологическом бульоне, в котором мы плаваем. Виной появлению данной статьи явилось то, что в кои-то веки выдался у меня отпуск, в течение которого решил я попробовать себя на поприще написания блогопостов по околохабровской тематике, и предлагаемая тема мне показалась вполне для этого подходящей. Кроме того, здесь я надесь получить конструктивную критику, и возможно понять чего же еще с этим можно сделать этакого интересного. В конце будет ссылка на github-репозиторий, в котором можно посмотреть код.

Всем привет!
После долгого перерыва блудный Python Meetup снова с нами. На долгожданной мартовской встрече сообщества любителей и профессионалов языка программирования Python обсуждались животрепещущие темы: противостояние Python и Erlang, а также дополнительные возможности PostgreSQL.
Видеозаписи выступлений под катом. Приятного просмотра!

Мы продолжаем готовиться к PG Day’16 и знакомить вас с интересными возможностями PostgreSQL.

В предыдущих постах этой серии я говорил о том, как читать вывод EXPLAIN и что означает каждая строка (операция/узел).

В заключительном посте я постараюсь объяснить, почему Постгрес выбирает «Операцию X», а не «Операцию Y».

Сегодня вышел Firebird 3.0 — шестой основной релиз СУБД Firebird, и он же — самый значительный по масштабу изменений с момента выхода 1-й версии в 2002 году,.
Архитектура Firebird 3.0 была переработана и теперь полностью поддерживает многопоточность с масштабированием до сотен ядер, эффективно поддерживается большое количество RAM. Согласно результатам нагрузочных тестов OLTP, имитирующим интенсивные вставки и изменения, скорость работы в сценариях с сотнями пользователей у Firebird 3.0 по сравнению с 2.5 возросла в ~5 раз.
Помимо масштабирования и производительности, релиз Firebird 3.0 включает в себя возможности шифрование БД, трафика, и более 100 новшеств в области SQL и безопасности — они подробно описаны в release notes и документации по языку SQL (на русском языке).

Самые важные ссылки по Firebird 3:

В этой статье я хочу рассказать про важную задачу, о которой нужно думать и нужно уметь решать, если в аналитической платформе для работы с данными появляется такой важный компонент как Hadoop — задача интеграции данных Hadoop и данных корпоративного DWH. В Data Lake в Тинькофф Банке мы научились эффективно решать эту задачу и дальше в статье я расскажу, как мы это сделали.



Данная статья является продолжением цикла статей про Data Lake в Тинькофф Банке (предыдущая статья Data Lake – от теории к практике. Сказ про то, как мы строим ETL на Hadoop).

Конференция PG Day’16 с каждым днем всё ближе, а мы продолжаем публиковать серию статей Hubert Lubaczewski об анализе explain и его основных операциях.

В этом, надеюсь, предпоследнем посте серии я расскажу об оставшихся наиболее распространенных операциях, которые вы можете встретить в выводе explain.

Каждый раз, продумывая программу DUMP, нам приходится решать одну и ту же задачу: как сделать так, чтобы как можно больше докладов оказалось интересно как можно большему числу участников конференции. Ведь они такие разные!

И каждый раз мы находим новые решения для этой задачи. Например, в этом году технический трек будет представлен аж в четырех специализированных секциях: FrontTalks, DevOps, Mobile и ServerSide. Каждая из них будет насыщенной и интересной, можете убедиться сами (обзор секций Mobile и DevOps на Хабре, программа FrontTalks).

Из всего многообразия интересных тем для бэкенд-разработчиков надо было выбрать всего 9 лучших. Как мы решили эту задачу и что в итоге получилось, читайте под катом.

В мануале есть всё. Но чтобы его целиком прочитать и осознать, можно потратить годы. Поэтому один из самых эффективных методов обучения новым возможностям Postgres — это посмотреть, как делают коллеги. На конкретных примерах. Эта статья может быть интересна тем, кто хочет глубже использовать возможности postgres или рассматривает переход на эту СУБД.

Первого апреля принято начинать новость с очередной «правдивой» истории. Утром я уже читал обзор инженерного образца AMD Zen. Но в случае с SQL Server, все действительно является правдой.

31 марта Tiffany Wissner (Senior Director of Data Platform Marketing) анонсировала, что теперь SQL Server 2014 Developer Edition является полностью бесплатным в рамках программы Visual Studio Dev Essentials. От всех желающих требуется только регистрация.

К слову будет сказано, что раньше Developer Edition стоил 59.95$ на одного разработчика.

Что дает бесплатность? Теперь не нужно мудрить с количеством лицензий, который выдаются на компанию в рамках программы партнёрства. Забыть про головную боль по переустановке Evaluation каждые 180 дней.

При сопровождении ERP систем иногда возникает необходимость массового изменения кода процедур, функций, триггеров или пакетов. Например для замены вызова одной процедуры на вызов другой.
Если надо поменять пару процедур, то можно сделать это в ручную, но когда надо изменить несколько сотен объектов, то приходиться задуматься об автоматизации процесса. В статье описан пример автоматизации для СУБД ORACLE 11g.

Это вторая часть цикла «Масштабирование 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-система), а значит кэш оперативной памяти обеспечит гораздо более высокую скорость чтения и снизит нагрузку на базу данных.

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

Есть вопросы, которые, казалось бы, не могут быть не решены. Слишком часто мы с ними встречаемся в повседневной жизни. Но посмотришь внимательно — и оказывается, нет, не решены. Все делают по-разному. И не всегда хорошо. Одним из таких вопросов является взаимодействие пользовательского интерфейса работы с таблицей и системы управления базами данных (СУБД).



Требования понятны. Данные должны отображаться быстро, создавать минимальную нагрузку на СУБД и работа с ними должна быть удобна пользователю. Решения вроде тоже все есть. Но все равно даже в очень успешных проектах применены технологии, которые заставляют предположить, что разработчики решили еще раз придумать “самое лучшее” решение.

Хотелось бы рассмотреть современные подходы к решению этой задачи и подумать, есть ли наилучший вариант. И, если нет, когда что лучше использовать.

Март выдался на удивление богатым на события. Не успел выйти SQL Server 2016 RC0, как уже доступен для загрузки RC1. Нововведений в последнем не сильно много, поэтому интересного обзора увы не получится.

Тем не менее, чтобы с пользой скоротать время, в ожидании релиза SQL Server 2016, предлагаю ознакомиться с докладами 24 Hours of PASS, которая прошла 16-17 марта.

Для тех, кто слышит про 24 Hours of PASS впервые… это ежегодная онлайн-конференция, посвященная SQL Server и длящаяся 24 часа. Докладчики из разных частей света сменяют друг друга и рассказывают много интересного про SQL Server. Существует несколько версий 24HOP. Русскоязычная версия данного мероприятия уже не первый год проводится усилиями Андрея Коршикова.

Чтобы не томить в ожидании, список видео-докладов, которые доступны под катом:

• SQL Server Transaction log. Внутреннее устройство и решение проблем (Андрей Завадский)
• XML, XQuery и трюки с производительностью (Сергей Сыроватченко)
• Azure ML. Определение наиболее эффективного классификационного алгоритма для выбранного источника данных (Константин Хомяков)
• SQL Server In-Memory OLTP: Нестандартные сценарии использования (Дмитрий Короткевич)
• SQL Server Extended Properties как простейший способ документирования баз данных (Вячеслав Миругин)
• SQL Server 2016 Reporting Services. Быстрый старт (Андрей Коршиков)
• Поддержка больших БД на MS SQL Server (Кирилл Панов)
• SQL Server 2016. Temporal Tables (Алексей Князев)
• 1+1=10. Использование битовых масок в базах данных (Елена Смоляк)
• SSAS Tabular 2016 (Евгений Полоничко)
• Внутри оптимизатора запросов: Query Store (в 2-х частях) (Дмитрий Пилюгин)
• PowerBI: Визуализация данных в реальном времени (Сергей Лунякин)
• Анализ производительности Windows приложений на примере SQL Server с использованием стандартного функционала операционной системы (Михаил Комаров)

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

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

В последствии данные обрабатываются до состояния пригодного к употреблению разнообразными пользователями. Это могут быть внутренние дашборды; отчёты партнёрам; результаты, которые идут в продакшн и влияют на поведение продукта. Эти операции могут быть довольно сложными и включать несколько источников данных. Но по большей части мы с этим справляется внутри BigQuery с помощью SQL+UDF. Результаты сохраняются в отдельные таблицы там же.