Сравнение большого числа баз данных

Системы мониторинга и анализа:

Contrib/pgbanch – простая программа для запуска benchmark тестов PostgreSQL
Cacti(www.cacti.net)/Nagious (www.nagios.org) – системы мониторинга различных параметров системы
Bonnie++(sourceforge.net/projects/bonnie) тестирование винта и файловой системы
pgFouine(pgfouine.projects.postgresql.org) – анализатор логов. Написан на пхп

Статьи

PostgreSQL Hardware Performance Tuning
Performance Tuning
Настройка производительности
Инструкция по оптимизации
GUCs: A Three Hour Tour

Также упоминался connection pooler from Skype pgBouncer

Если у кого то есть еще интересные ссылки по теме, то кидайте, буду только рад. Спасибо.

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

Доделал один сайт, и поиск к нему решил прикрутить не стандартный фуллтекст индекс из PostgreSQL а прицепить сюды енджин сторонний. Выбор мой остановился на Shinx ( сразу скажу, я не проводил углублённых анализов, на тему какой же движок заюзать. Это не надо пока. ) . Да, и есть маленькое затруднение в поиске инфы — я когда гуглил, то все время переципался через генератор документации для питона, с таким же названием.

Так. От слов к делу.

на форуме у них нашёл описание настройки под Debian. Так что ниже кратко:

Далее в секции searchd должно быть:

В секции index:

И запуск

На этом месте должен уже работать демон.

Вот скрипт пепеиндексирования всех индексов

Далее добавляем свой индекс:

после этого создаем папку /var/sphinx/data/, переиндексируем, разрешим демону пользоваться нашими файлами

и передерним демона:

Теперь надо рассказать джанге, как им надо пользоваться. Инсталим django-sphinx

я ставил 0.9.8, так что в settings.py вашего проекта прописываем :

SPHINX_API_VERSION = 0×113

в моделе, по которой вы хотите вести поиск привязываем свойство, с указанием весов полей.

Вот и все. Последнее — это выполнить поиск:

Вот так кратко, сухо, критикуйте!

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

Итак немного предыстории и введение в проблематику.

Я веду один из банковских проектов — написания и сопровождения CashPay терминалов. И изначально решение предназначалось именно для них, хотя и для других моих проектов — это тоже будет хорошим дополнением.

От слов к делу. Как выглядит лог, например, лайти. Вот одна запись:
10.55.6.59 10.55.6.57 – [19/Jan/2009:15:56:39 +0200] “POST /index.cgi HTTP/1.1″ 200 31 “-” “libwww-perl/5.812″

Что какое поле тут означает – я распинатся не будут. Просто скажу, что для этих логов, и для многих других как правило все сводится к определённому формату.

1.Всегда есть время. И даже если его нет, то как правило — это ПОКА нет. Т.к. вообще теряется сам смысл ведения логов.
2.Есть какая то служебная инфа, присутствующая во всех записях. Это может быть айди процесса, который сейчас пишет лог, или айди пользователя, который сейчас совершает действия.
3.Собственно данные которые вы хотите сохранить для потомков, которые будут разгребать ваши баги. Иногда их подписывают фразами (error, debug, info) Это необходимо для некой группировки логов.

Кажется ничего не забыл. Как правило — этого достаточно. Для чего?

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

Мое решение — логи в CSV формате. Идея реально не нова. Я ее подсмотрел в постгрисе, если его не привязывать к syslog, то свои логи он пишет именно так. Плюс, один мой друг, высказывал идею ведения логов в базе. По окончанию получился некий сембиоз идей.

Итого, ведя логи в CSV — можно вести их легко и быстро + для анализа можно ипортировать их в любую удобную для вас БД.
В PostgreSQL это делается одной командой.

COPY tables_for_log FROM ‘/full/path/to/logfile.csv’ WITH csv;

На самом деле уже это дает очень много плюсов. Хотя бы то, что теперь процесс анализа логов может сводится к простому пользовательскому интерфейсу, в котором вы на первом шаге выбираете даты и возможно сервисы, по которым вам необходимо искать данные. На следующем этапе находятся необходимые логи, распаковываются при необходимости, импортируются в БД и выводится инфа и совершенном импорте. Далее у вас просто текстовое поле, в котором вы оперируете SQL командами для выдачи результатов по логам. Это текстовое поле вам необходимо будет только для начала, чтоб понимать какого рода выборки вам необходим будет делать для решения проблем. После все можно будет свести уже к более удобным интерфейсам. Но это уже будет для каждого проекта своё и глубже я заходить не буду.

Ещё одним неоспоримым плюсом является то, что если две системы друг с другом взаимодействуют и пишут логи в одинаковых ( или сходных друг с другом ) форматах, то вы можете импортировать эти логи в одну таблицу вашей БД. И уже в одном сплошном листинге наблюдать процесс взаимодействие двух сервизов друг с другом. Мне кажется это очень удобным, т.к. в одном из моих проектов таких взаимодействующих систем 4. И процедура поиска ошибки просто выматывает. Да и можно проводить автоматическое тестирование работы систему уже по её результатам ( но про это я рассказывать не буду, потому что подходов много, а решений ещё больше)

Далее, если развивать идею ведения логов, то очевидно, что в любой системе, либо сервисе — есть событие и есть реакция системы на это событие. Запрос урла к вашему серверу — есть событием, а то, что ваш сервер начал делать выборки из базы, изменять её, формировать ответ и выдавать пользователю результат — это уже реакция системы на произошедшее событие. Таким образом я предлагаю разделать на два лога (два CSV файла), и связывать их как один ко многим. Как поле связи можно использовать время, когда было получено событие в миллисекундах. Итого в первую таблицу мы кладем события. Для веб сайтов это может быть время, урл, куки, пост данные, айди пользователя. Вторая таблица уже куда более привязана к конкретному проекту, туда мы сбрасываем все трейсы переменных, возможно ошибки, короче все, что вы до этого писали в логи. Но обязательно должно быть время события ( для связи), время лога. Дальше можно разделить код на компоненты и в логах записывать название компонентов в которых они ведутся, можно просто записывать имя модуля и имя функции. На самом деле вариантов масса. Но я бы всегда разбивал логи по степени важности (debug, info, error)

Все, идеи по логам кончились. Примеров реализации пока не выкладываю, ну просто потому, что там реально будет строк 20 кода. А вообще как вам идея?

Спонсор поста Вывоз мусора в Москве ( у них я взял картинку )

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

К слову говоря, на том же сайте, новость о встреча профессионалов в области двух “конкурирующих” СУБД.

* Используйте постоянные подключения к базе данных, чтобы избежать накладных расходов на текущие подключения. Если Вы не можете использовать постоянные подключения, и Вы делаете много новых подключений, стоит изменить значение переменной thread_cache_size
* Обязательно проверьте, что все Ваши запросы в самом деле используют индексы, которые Вы создали в таблицах. В MySQL Вы можете сделать это командой EXPLAIN.
* Избегайте сложных запросов SELECT на таблицах, которые часто модифицируются. Это должно помочь избежать проблем с блокировкой таблицы.
* Новые таблицы MyISAM могут вставлять строки в таблицу без удаленных строк в то же самое время, когда другой запрос ведет чтение. Если это важно для Вас, Вы должны рассмотреть методы, где Вы не должны удалить строки или выполните OPTIMIZE TABLE после того, как Вы удалили много строк сразу.
* Используйте вызов ALTER TABLE … ORDER BY expr1,expr2… если Вы обычно получаете строки в порядке expr1,expr2,… . Используя эту опцию после внесения больших изменений для таблицы, Вы можете получить значительно более высокую эффективность.
* В некоторых случаях может иметь смысл представлять столбец, который является хэшем, основанным на информации из других столбцов. Если этот столбец короткий и приемлемо уникальный, это может быть намного быстрее, чем большой индекс на многих столбцах. В MySQL это очень легко в использовании: SELECT * FROM table_name WHERE hash=MD5(concat(col1,col2)) AND col_1=’constant’ AND col_2=’constant’
* Для таблиц, которые часто изменяются, Вы должен пробовать избежать любых столбцов типов VARCHAR или BLOB. Вы получите динамическую длину строки, как только Вы используете хоть один стобец VARCHAR или BLOB.
* Если Вы очень часто должны вычислять значения, основанные на информации из большого количества строк (подобно количеству), вероятно, намного лучше представить новую таблицу и модифицировать счетчик в реальном времени. Модификация типа UPDATE table set count=count+1 where index_column=constant очень быстрая! Это действительно важно, когда Вы используете базы данных подобные MySQL, которые имеют только блокировку уровня таблицы. Это также даст лучшую эффективность с большинством баз данных, поскольку администратор блокировки строки в этом случае будет иметь куда меньше работы.
* Если Вы должны собрать статистику из больших таблиц файла регистрации, используйте итоговые таблицы вместо того, чтобы просмотреть целую таблицу. Поддержание резюме должно быть намного быстрее, чем попытка сделать живую статистику. Намного быстрее получить новые итоговые таблицы из файлов регистрации, когда происходит изменение, чем менять работающее приложение!
* Если возможно, нужно классифицировать отчеты как “живые” или “статистические”, где данные, необходимые для статистических отчетов, сгенерированы только, исходя из итоговых таблиц, которые в свою очередь были сгенерированы из фактических данных.
* Воспользуйтесь преимуществом того факта, что столбцы имеют значения по умолчанию. Вставляйте значения явно только, когда значение, которое будет вставлено, отличается от значения по умолчанию. Это уменьшает синтаксический анализ, который MySQL должен сделать, и улучшает быстродействие вставки.
* В некоторых случаях удобно упаковывать и сохранить данные в blob. В этом случае Вы должны добавить некоторый дополнительный код к Вашей прикладной программе, чтобы упаковать/распаковать данные, но это может сохранить много времени доступа в некоторой стадии. Это удобно, когда Вы имеете данные, которые явно не соответствуют статической структуре таблицы.
* Обычно Вы должны пробовать хранить все данные неизбыточными (что названо третьей нормальной формой в теории базы данных), но Вы не должны бояться дублирования или создания таблиц-резюме, если Вы нуждаетесь в них, чтобы получить большее быстродействие.
* Сохраненные процедуры или UDF (определяемой пользователем функции) может быть хорошим способом получить большую эффективность. В этом случае Вы должны, однако, всегда иметь способ делать это некоторым другим (более медленным) путем, если Вы используете СУБД, которая не поддерживает это.
* Вы можете всегда получать неплохие результаты, кэшируя запросы/ответы в Вашей прикладной программе и пробуя делать много вставок/модификаций в то же самое время. Если Ваша база данных поддерживает блокировки таблиц (подобно MySQL и Oracle), это должно помочь гарантировать, что индексный кэш сбрасывается только однажды после выполнения всех модификаций.
* Используйте INSERT /*! DELAYED */, если Вы не должны знать, когда Ваши данные будут записаны. Это ускоряет дела потому, что много записей могут быть выполнены за один дисковый обмен.
* Используйте INSERT /*! LOW_PRIORITY */, когда Вы хотите, чтобы Ваши вызовы select были более важными.
* Используйте SELECT /*! HIGH_PRIORITY */, чтобы получить select, обходящий очередь. То есть select будет выполнен, даже если имеется кто-то ждущий, чтобы сделать запись в таблицу.
* Используйте многострочную инструкцию INSERT, чтобы сохранить много строк одной командой SQL (многие серверы SQL поддерживают это).
* Используйте LOAD DATA INFILE, чтобы загрузить большие количества данных. Это быстрее, чем нормальные вставки, а будет еще быстрее, когда myisamchk интегрирован в mysqld.
* Используйте столбцы с поддержкой AUTO_INCREMENT, чтобы сделать уникальные значения.
* Используйте OPTIMIZE TABLE время от времени, чтобы избежать фрагментации при использовании динамического формата таблицы.
* При использовании нормальной установки Web-сервера, изображения должны быть сохранены как файлы. То есть сохраните только ссылку на файл в базе данных. Основная причина для этого в том, что нормальный Web-сервер намного лучше при кэшировании файлов, чем содержание базы данных. Так что намного проще получить быструю систему, если Вы используете файлы.
* Используйте таблицы в памяти для некритических данных, к которым обращаются часто (подобно информации относительно последнего показанного баннера для пользователей, которые не имеют cookie).
* Столбцы с идентичной информацией в различных таблицах должны быть объявлены идентично и иметь одинаковые имена. До Version 3.23 Вы получали медленные объединения в противном случае. Старайтесь делать имена проще (например, name вместо customer_name в таблице заказчиков). Чтобы сделать Ваши имена переносными на другие SQL-серверы, Вы должны озаботиться тем, чтобы они не превышали в длину 18 символов.
* Объявление таблицы с DELAY_KEY_WRITE=1 будет делать модифицирование индексов быстрее, поскольку они не регистрируются на диске, пока файл не закрыт. Обратная сторона в том, что Вы должны выполнить myisamchk на этих таблицах прежде, чем Вы запускаете mysqld, чтобы гарантировать, что они правильные, если что-то уничтожило mysqld в середине запроса. Поскольку информация ключа может всегда генерироваться из данных, Вы не должны терять что-нибудь, используя DELAY_KEY_WRITE.

Использовался материал:

1) newcontinent.ru

2) dev.mysql.com

Сразу скажу, что в перле нет DBD::MSSQL, лично у меня – это сразу паника. Ну ничего. Есть такая умная штука как ODBC (Open DataBase Connectivity) она была создана именно для того, чтоб универсализировать доступ к различным типам баз данных, и по сути из себя представляет интерфейс. Я когда в буйной молодости кодил под винду, то сталкивался с этим, но тогда особо не заморачивался на тему «что оно такое?», и «как работает?». Так вот в линуксе есть подобная штука. Называется она unixODBC. ЕЕ и ставим.

Устанавливаем unixODBC.

Единственная проблема, что стандартные сошники есть только для MySQL и PostgreSQL. А на официальном сайте я нашел драйвер для Microsoft SQL Server – он прям там красуется на первом месте, но не могет не смущать надпись «Download free trial from…»

В этом случае спасает FreeTDS – это и есть те самые библиотеки для общения с Microsoft SQL Server и Sybase. И с ним тоже при установке не должно быть никаких проблем.

Не забываем поставить модуль для DBI.

дальше добавляем конфиг

в файл /etc/odbcinst.ini

На этом конфигурация закончена. В перле это происходит так:

пдыЩ

сам то я пользуюсь mysql, но уже пора бы начинать пробывать и это