Рубрика «db»

Сколько проектов можно разрабатывать одновременно? Вопрос звучит неоднозначно. С одной стороны, на процесс влияет человеческий фактор, с другой – технические ограничения.

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

Читать полностью »

Всем привет. На связи Владислав Родин. В настоящее время я преподаю на портале OTUS курсы, посвященные архитектуре ПО и архитектуре ПО, подверженного высокой нагрузке. В преддверии старта нового потока курса «Архитектор высоких нагрузок» я решил написать небольшой авторский материал, которым хочу поделиться с вами.

Почему может понадобится полусинхронная репликация? - 1


Введение

Из-за того, что на HDD может выполняться лишь порядка 400-700 операций в секунду (что несравнимо с типичными rps'ами, приходящимися на высоконагруженную систему), классическая дисковая база данных является узким горлышком архитектуры. Поэтому необходимо уделить отдельное внимание паттернам масштабирования данного хранилища.

На текущий момент имеются 2 паттерна масштабирования базы: репликация и шардирование. Шардирование позволяет масштабировать операцию записи, и, как следствие, снижать rps на запись, приходящийся на один сервер вашего кластера. Репликация позволяет делать тоже самое, но с операциями чтения. Именно этому паттерну и посвящена данная статья.Читать полностью »

Что делать, когда имеется приложение с закрытым исходным кодом, которое обращается к БД не самым оптимальным образом? Как потюнить запросы, не меняя приложение, а возможно и саму БД?

Если вы не задавались такими вопросами — вы очень успешный и строгий DBA.

Ну а если задавались — позвольте поделиться страданиями и опытом.
Читать полностью »

Я не буду учить твой Garbage Query Language - 1

Это будет немного напыщенная речь, но меня действительно раздражает софт, в котором люди пытаются изобрести очередной собственный язык запросов. У нас уже есть триллион различных ORM, еще триллион баз данных с собственным языком запросов каждая, и еще триллион SaaS-продуктов, для доступа к которым нужно освоить какой-нибудь очередной DSL, которые они придумали.

Верните мне мой SQL обратно. Это язык понятный каждому, существует аж с 70-х и за это время успел стать стандартом. Он прост в чтении и может использоваться кем угодно, от бизнеса до инженеров.

Однако вместо этого мне приходится изучать целый ворох разных "garbage query language", потому что люди по-прежнему пытаются изобрести колесо заново.

Читать полностью »

image

Joomla очень плохо переваривает базу данных даже с несколькими тысячами статей в таблице _content. При нескольких десятках тысяч запросы в базу стандартных модулей типа mod_articles_popular могут зависать на секунды.

Всё дело в ACL (Access Control List) — политике контроля доступа. Проверка законности доступа пользователя к материалам занимает свыше 98% времени выполнения запроса.Читать полностью »

image

Прилетела мне недавно задача дополнить функционал одной довольно старой програмки (исходного кода программы нет). По сути нужно было просто сканить периодически БД, анализировать информацию и на основе этого совершать рассылки. Вся сложность оказалась в том, что приложение работает с БД c-tree, написанной аж в 1984 году.

Порывшись на сайте производителя данной БД нашёл некий odbc драйвер, однако у меня никак не получалось его подключить. Многочисленные гугления так же не помогли нормально сконнектиться с базой и доставать данные. Позже было решено связаться с техподдержкой и попросить помощи у разработчиков данной базы, однако ребята честно признались что уже прошло 34 года, всё поменялось 100500 раз, нормальных драйверов для подключения на такое старьё у них нет и небось уже тех программистов в живых тоже нету, которые писали сие чудо.
Порывшись в файлах БД и изучив структуру, я понял, что каждая таблица в БД сохраняется в два файла с расширением *.dat и *.idx. Файл idx хранит информацию по id, индексам и т.д. для более быстрого поиска информации в базе. Файл dat содержит саму информацию, которая хранится в табличках.

Решено было парсить эти файлики самостоятельно и как-то добывать эту информацию. В качестве языка использовался Go, т.к. весь остальной проект написан на нём.
Читать полностью »

image

Привет %username%,

Сегодня я хотел бы рассказать про достаточно тривиальную задачу сбора логов с децентрализованных Squid proxy серверов и подводные камни с которыми мы столкнулись.

Что имеем:

  1. Squid-hq
  2. Squid-br1
  3. Squid-br2
  4. Squid-br3
  5. Squid-br4
  6. Squid-db

Читать полностью »

Python DB-API – это не конкретная библиотека, а набор правил, которым подчиняются отдельные модули, реализующие работу с конкретными базами данных. Отдельные нюансы реализации для разных баз могут отличаться, но общие принципы позволяют использовать один и тот же подход при работе с разными базами данных.

Python: Работа с базой данных, часть 1-2: Используем DB-API - 1

В статье рассмотрены основные методы DB-API, позволяющие полноценно работать с базой данных. Полный список можете найти по ссылкам в конец статьи.

Требуемый уровень подготовки: базовое понимание синтаксиса SQL и Python.
Читать полностью »

image

Ранее я уже публиковал статью о том, как генерировать фиктивные данные при помощи Elizabeth — библиотеки для языка программирования Python. Статья, которую вы читаете является продолжением предыдущей, потому я не буду приводить основ работы с библиотекой. Если вы пропустили статью, поленились прочитать или просто не захотели, то, вероятно, захотите сейчас, ибо эта статья подразумевает, что читатель уже знаком с основами библиотеки. В этой части статьи я буду говорить о том, каким образом организовывать генерацию фиктивных данных в собственных приложениях, расскажу о нескольких, на мой взгляд, полезных особенностях библиотеки.

Читать полностью »

Для дотошных

В последнее время в среде разработчиков серверных приложений часто возникают споры о том, как лучше управлять фалами и какая технология обеспечивает более быстрые чтение/запись файлов. В сети стали появляться статьи и статейки о сравнительной производительность локальной файловой системы и GridFS. Или о хранении файлов в реляционной базе как BLOB против хранения на жёстком диске в файловой системе. Вот и я решил ввязаться в этот противостояние. Сегодня мы будем сравнивать производительность и накладные расходы MongoDB 2.6.7 x64 GridFS против MS SQL Server Express 2012 v11.0.5058.0 x64 против NTFS. Для эксперимента была использована платформа Windows 7 x64 SP1 на AMD Athlon(tm) II X2 250 Processor 3.00 GHz c 4ГБ ОЗУ 1033 MHz и HDD 600 Gb SATA 6Gb/s Western Digital VelociRaptor 10000rpm 32Mb. После каждого теста компьютер перезапускался, а базы обнулялись. Производительность будем рассматривать на примере файлового сервера на C# под .NET 4.5, код которого прикреплён к статье.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js