Так как колоночная СУБД ClickHouse (внутренняя разработка Яндекс) стала доступна каждому, решил использовать эту СУБД заместо MongoDB для хранения аналитических данных. Перед использованием сделал небольшой тест производительности и хочу поделиться результатами с IT сообществом.
Читать полностью »
Рубрика «sql» - 54
Небольшое сравнение производительности СУБД «MongoDB vs ClickHouse»
2017-01-29 в 23:27, admin, рубрики: big data, clickhouse, mongdb, mongodb, nosql, sqlБрошюра об Ecto – интерфейсе для работы с базами данных на Elixir
2017-01-25 в 3:22, admin, рубрики: active_record, ecto, Elixir, Elixir/Phoenix, phoenix, rails, ruby, sql
Вступление
Ecto написанный на Elixir DSL для коммуникации с базами данных. Ecto это не ORM. Почему? Да, потому что Elixir не объектно-ориентированный язык, вот и Ecto не может быть Object-Relational Mapping (объектно-реляционным отображением). Ecto — это абстракция над базами данных состоящая из нескольких больших модулей, которые позволяют создавать миграции, объявлять модели (схемы), добавлять и обновлять данные, а также посылать к ним запросы.
Если вы знакомы с Rails, то для вас самой близкой аналогией, конечно же, будет его ORM ActiveRecord. Но эти две системы не являются копиями друг друга, и хороши в использовании в рамках своих базовых языков. На данный момент актуальная версия Ecto 2, она совместима с PostgreSQL и MySQL. Более ранняя версия дополнительно имеет совместимость с MSSQL, SQLite3 и MongoDB. Независимо от того, какая используется СУБД, формат функций Ecto будет всегда одинаковый. Также Ecto идёт из коробки с Phoenix и является хорошим стандартным решением.
Если надумаете расширить брошюру, то милости прошу присоединиться к развитию данного репозитория https://github.com/wunsh/ecto-book-ru
Новшества Ecto 2.X
jl-sql: работаем с JSON-логами в командной строке с помощью SQL
2017-01-18 в 13:10, admin, рубрики: cli, data mining, javascript, json, json logs, node.js, sql, terminal, ПрограммированиеВступление никому не интересно, поэтому начну сразу с примеров использования
% cat log.json{"type": "hit", "client": {"ip": "127.1.2.3"}}
{"type": "hit", "client": {"ip": "127.2.3.4"}}
{"type": "hit", "client": {"ip": "127.3.4.5"}}
{"type": "hit", "client": {"ip": "127.3.4.5"}}
{"type": "hit", "client": {"ip": "127.1.2.3"}}
{"type": "click", "client": {"ip": "127.1.2.3"}}
{"type": "click", "client": {"ip": "127.2.3.4"}}Выполняем запрос:
% cat log.json | jl-sql 'SELECT client.ip, COUNT(*) AS count WHERE type = "hit" GROUP BY client.ip'{"client":{"ip":"127.1.2.3"},"count":2}
{"client":{"ip":"127.2.3.4"},"count":1}
{"client":{"ip":"127.3.4.5"},"count":2}И снова о рекурсивных запросах
2017-01-09 в 11:58, admin, рубрики: postgres, postgresql, Query, recursive, sql, window functions, Блог компании Postgres ProfessionalВ этой заметке речь пойдет о том, как писать рекурсивные запросы. Тема эта поднималась не раз и не два, но обычно все ограничивается простыми «деревянными» случаями: спуститься от вершины до листьев, подняться от вершины до корня. Мы же займемся более сложным случаем произвольного графа.
Начнем с того, что повторим теорию (очень кратко, потому что с ней все ясно), а затем поговорим о том, что делать, если непонятно, как подступиться к реальной задаче, или вроде бы понятно, но запрос упорно не хочет работать.
Для упражнения будем использовать демо-базу, подробно описанную ранее, и попробуем написать в ней запрос для поиска кратчайшего пути из одного аэропорта в другой.
Производительность запросов в PostgreSQL – шаг за шагом
2017-01-05 в 19:38, admin, рубрики: postgresql, sql, Блог компании Конференции Олега Бунина (Онтико), высокая производительность, илья космодемьянский, оптимизация запросов, метки: илья космодемьянский
Илья Космодемьянский (
hydrobiont )
Для начала сразу пару слов о том, о чем пойдет речь. Во-первых, что такое оптимизация запросов? Люди редко формулируют и, бывает так, что часто недооценивают понимание того, что они делают. Можно пытаться ускорить какой-то конкретный запрос, но это не обязательно будет оптимизацией. Мы немного на эту тему потеоретизируем, потом поговорим о том, с какого конца к этому вопросу подходить, когда начинать оптимизировать, как это делать, и как понять, что какой-то запрос или набор запросов никак нельзя оптимизировать – такие случаи тоже бывают, и тогда нужно просто переделывать. Как ни странно, я почти не буду приводить примеров того, как запросы оптимизировать, потому что даже 100 примеров не приблизят нас к разгадке.
Читать полностью »
День добрый. Большинство продуктов, с которыми сталкивается разработчик, обычно требуют развертывания на нескольких машинах, которые работают независимо друг от друга. Это порождает одну из типовых проблем — расхождение базы данных на разных серверах, несоответствие идентификаторов в таблицах-справочниках и разумеется неоднородность в силу невнимательности и пропущенных патчей при обновлении БД на конкретной машине. В некоторых случаях это выливается в дикие (на мой наивный взгляд) концепции типа «мы столбцы никогда не удаляем — только добавляем».
В других и вовсе приводит к засорению базы мусором с других площадок и к ошибкам после «простейшего мержа».
Знакомых с такими ситуациями, критиков и знающих точно, что я изобрел велосипед — приглашаю под кат.
Читать полностью »
Сравнение производительности аналитической СУБД Exasol и Oracle In-Memory Option
2016-12-25 в 22:21, admin, рубрики: big data, dwh, exasol, oracle, oracle database, sql, высокая производительность, сравнение производительности, метки: exasol
Свою предыдущую статью я посвятил тому, как и на сколько можно ускорить аналитические (типовые для OLAP/BI систем) запросы в СУБД Oracle за счёт подключения опции In-Memory. В продолжение этой темы я хочу описать несколько альтернативных СУБД для аналитики и сравнить их производительность. И начать я решил с in-memory RDBMS Exasol.
Для тестов, результаты которых я публикую, выбран TPC-H Benchmark и при желании читатели могут повторить мои тесты.
Читать полностью »
Уровни изоляции транзакций с примерами на PostgreSQL
2016-12-22 в 18:00, admin, рубрики: isolation levels, postgresql, read committed, serializable, sql, transactions, Разработка веб-сайтовВступление
В стандарте SQL описывается четыре уровня изоляции транзакций — Read uncommited (Чтение незафиксированных данных), Read committed (Чтение зафиксированных данных), Repeatable read (Повторяемое чтение) и Serializable (Сериализуемость). В данной статье будет рассмотрен жизненный цикл четырёх параллельно выполняющихся транзакций с уровнями изоляции Read committed и Serializable.
Для уровня изоляции Read committed допустимы следующие особые условия чтения данных:
Неповторяемое чтение — транзакция повторно читает те же данные, что и раньше, и обнаруживает, что они были изменены другой транзакцией (которая завершилась после первого чтения).
Фантомное чтение — транзакция повторно выполняет запрос, возвращающий набор строк для некоторого условия, и обнаруживает, что набор строк, удовлетворяющих условию, изменился из-за транзакции, завершившейся за это время.
Что же касается Serializable, то данный уровень изоляции самый строгий, и не имеет феноменов чтения данных.
«Распределение в запросе» или «избавляемся от перебора»
2016-12-22 в 15:54, admin, рубрики: sql, высокая производительность, оптимизация запросов, перебор, Программирование, распределение в запросеХороший перебор — это отсутствие перебора. Рассмотрим пример замены полного перебора запросом.
В свое время, года 3 назад, возникла необходимость оптимизации конфигурации 1С и устранения ее узких мест в одной компании. Одним из таких узких мест оказался, казалось бы, безобидный, механизм распределения товаров в реализации по сериям. Суть в том, что строк распределялось достаточно много и было это очень медленно. Не миллионы за раз, конечно, но на это самое распределение для одного документа могло уходить до минуты.
Запрос специально привожу на T-SQL, т.к. думаю, что Хабравцам это будет ближе.
Читать полностью »
История СУБД Oracle — первой коммерчески успешной реляционной СУБД
2016-12-22 в 15:48, admin, рубрики: oracle, sql, базы данных, конкуренция, ларри эллисон, реляционные базы данных, СУБД
До середины 70-х годов информация в базах данных распределялась по старинному иерархическому, или «древовидному», принципу, который до сих пор используется в настольных операционных системах.
Первые прототипы реляционных СУБД существовали уже в 70-е годы ХХ века. Однако мало кто верил в возможность добиться эффективной реализации таких систем. Тем не менее, к концу 1980-х годов реляционные системы заняли на мировом рынке СУБД доминирующее положение.
В связи с этим многие компании стали позиционировать свои СУБД как «реляционные» в рекламных целях. Но далеко не всегда они имели для этого достаточно оснований. Поэтому автор реляционной модели данных Эдгар Кодд в 1985 году опубликовал свои знаменитые «12 правил Кодда», которым должна удовлетворять каждая РСУБД.
Одним из первых прототипов реляционных баз данных была система System R. Это проект компании IBM, который появился в 1976 году. Он вдохновил будущих основателей Oracle на создание собственной реляционной СУБДЧитать полностью »