Сравнение хранилищ данных для MySQL с поддержкой транзакций


Оглавление (нажмите, чтобы открыть):

Хранение файлов в базе vs хранение в файловой системе

Хотелось бы увидеть + и — различных видов хранения, и когда какой лучше использовать.

С файловыми таблицами, я не работал, но я предполагаю, что там меньше головной боли с файловыми операциями, например файл не может быть блокироваться процессом, наверное есть транзакции(Т.е нельзя убить файл, если вдруг при добавлении его в таблицу, клиент отвалится). Поправьте если я не прав.

UPD: Enttity Framework дружит с файловыми таблицами?

1 ответ 1

В SqlServer вы можете использовать следующие варианты (некоторые из них применимы и к другим СУБД).

Вариант 1

В БД хранится «заголовок» файла (например, путь к файлу плюс, возможно, какой-то набор атрибутов):

а данные хранятся отдельно в файловой системе. Размер БД меньше, чем если хранить в БД также и данные. Но нужно следить за ситуациями «файл есть, заголовка нет» или «заголовок есть, файла нет». На мой взгляд, если файлы являются логически важной частью данных БД (не кэш, не какие-то временные данные), то лучше посмотреть на другие варианты.

Вариант 2

В БД хранится также и содержимое файла (в столбце типа varbinary(max) ).

Здесь две опции — с FILESTREAM и без.

  • данные хранятся в БД (в т.н. LOB pages)
  • размер данных одного элемента ограничен 2Gb
  • данные хранятся в файловой системе (именно как файлы)
  • нет ограничения в 2Gb на элемент
  • данные FILESTREAM не участвуют при подсчёте лимита на макс. размер БД (к чему чувствительны Express Edition)
  • к данным можно получить доступ через соотв. API со стороны файловой системы
  • (SqlServer 2014 и далее) запрашиваемые данные не отъедают из buffer pool, оставляя больше памяти для обработки запросов

И с FILESTREAM и без поддерживаются транзакции. С FILESTREAM при доступе через Transact-SQL поддержка полная, при доступе через файловую систему есть ограничения (смотреть здесь).

Вариант 3

Использование таблиц специального типа FileTable.

Их функционал основан на использовании FILESTREAM . Таблица представляет иерархию хранящихся файлов/директорий, их данные и атрибуты. В варианте 2, чтобы создать/удалить файл, нужно создать/удалить соотв. запись в таблице. В данном варианте это можно делать напрямую через файловую систему. Например зайти в соответствующую директорию (SqlServer создаёт для этого соответствующую UNC share), создать какой-то файл/директорию, удалить/изменить, потом сделать запрос select * from FileTableName и увидеть соответствующие изменения. И наоборот — при вставке записи в таблицу через SQL в директории появится соответствующий файл или директория.

Какой вариант когда лучше использовать — думаю, зависит от конкретной задачи. В документации более детальное описание и сравнение вариантов 2 и 3.

MySQL — выбираем тип хранения данных MyISAM или InnoDB

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

Самыми популярными на сегодня являются MyISAM и InnoDB.

MyISAM интересен тем, что дает просто безумную скорость на select-ах и insert-ах. С другой стороны, он не поддерживает транзакционность и блокировку на уровне строк, что в свою очередь приводит к страшным тормозам при использовании delete\update. Проще говоря, на таблицу допускается только одна одновременная delete или update операция, и остальные вынуждены ждать завершения текущей операции, что на больших объемах данных приводит к серьезным проблемам.

К преимуществам движка можно отнести поддержку полнотекстовый поиск, компрессию и GIS функции. Под хранение каждой таблицы отводятся два файла – имя_таблицы.MYD ( данные ) и имя_таблицы.MYI ( индексы ). Формат данных платформенно независимый, что позволяет переносить данные с сервера на сервер простым копированием таблиц – это еще один плюс.

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

Кроме транзакционности, к преимуществам этого движка можно отнести row-level блокировки, правда тут стоит учесть тот факт, что table-level блокировки тоже имеют место быть, например при использовании автоинкрементных полей. С этим борятся и время от времени выходят фиксы, уменьшающие количество table-level блокировок, но никто не отменял регулярный просмотр логов на предмет проблем с блокировками.

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

Что может повлиять на выбор тиха хранения данных? Ну во-первых необходимость транзакционности, ибо если пишется серьезный финансовый софт, например тот же биллинг или процессинг, то тут майсам использовать никак нельзя.

Кроме того, специфика работы с данными, накладывает свой отпечаток на выбор движка. Если речь идет о какой-то статистике, которую все просто напросто просматривают, то лучше майсам с этим никто не справится.

Про конкурентность забывать тоже не стоит. Если работа с данными идет всего в несколько потоков, то это вполне может нивелировать недостатки myisam в плане update\delete в пользу быстрых select.

При выборе движка есть еще ряд нюансов, которые не так важны как главные критерии, но которые тоже стоит учитывать.

  • Многие жалуются на частые поломки MyISAM. Лично мне ни разу не доводилось с этим сталкиваться, потому ничего не могу сказать по этому поводу. Но надежность данных – это еще один аргумент в пользу innodb, который и крешит реже и восстанавливается быстрее.
  • Каждый движок требует свой “кусок пирога”. Мало перекинуть данные в myisam – нужно чтобы сервер был сконфигурирован так, чтобы этому движку было выделено достаточно ресурсов, иначе поимеем те же самые тормоза. Впрочем, сводных данных для отчетов по статистике не обязательно будет много!
  • Если данных немного, например той же статистики, то можно использовать тот же движок что и вся остальная база. По крайней мере лишите себя гемора поддержки двух движков.

Введение в транзакции в MySQL

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

Любая транзакция либо выполняется полностью, либо не выполняется вообще.

В транзакционной модели есть два фундаментальных понятия: COMMIT и ROLLBACK. COMMIT означает фиксацию всех изменений в транзакции. ROLLBACK означает отмену (откат) изменений, произошедших в транзакции.

При старте транзакции все последующие изменения сохраняются во временном хранилище. В случае выполнения COMMIT, все изменения, выполненные в рамках одной транзакции, сохранятся в физическую БД. В случае выполнения ROLLBACK произойдет откат и все изменения, выполненные в рамках этой транзакции, не сохранятся.

В MySQL транзакции поддерживаются только таблицами innoDB. Таблицы MyISAM транзакции не поддерживают. В innoDB по умолчанию включен autocommit, это значит, что по умолчанию каждый запрос эквивалентен одной транзакции.

Транзакция начинается со специального запроса «START TRANSACTION», либо «BEGIN». Чтобы закончить транзакцию, нужно либо зафиксировать изменения (запрос COMMIT), либо откатить их (запрос ROLLBACK).

Пример с COMMIT:

Пример с ROLLBACK:

В MySQL не существует механизма вложенных транзакций. Одно соединение с БД — одна транзакция. Новая транзакция в пределах одного соединения может начаться только после завершения предыдущей.

Для некоторых операторов нельзя выполнить откат с помощью ROLLBACK. Это операторы языка определения данных (Data Definition Language — DDL). Сюда входят запросы CREATE, ALTER, DROP, TRUNCATE, COMMENT, RENAME.

Следующие операторы неявно завершают транзакцию (как если бы перед их выпол­нением был выдан COMMIT):

  • ALTER TABLE
  • DROP DATABASE
  • LOAD MASTER DATA
  • SET AUTOCOMMIT = 1
  • BEGIN
  • DROP INDEX
  • LOCK TABLES
  • START TRANSACTION
  • CREATE INDEX
  • DROP TABLE
  • RENAME TABLE
  • TRUNCATE TABLE

Обратите внимание, что в случае SQL ошибки, транзакция сама по себе не откатится. Обычно ошибки обрабатываются уже с помощью sql wrapper’ов в самом приложении, таких как PHP PDO например. Если вы захотите откатывать изменения в случае ошибки прямо в MySQL, можно создать специальную процедуру и уже в ней выполнять ROLLBACK в обработчике :

Но этот способ скорее просто для ознакомления, а не руководство к действию. Почему? Я крайне не рекомендую так поступать, так как в основном ошибки базы данных обрабатываются с помощью SQL оберток на стороне приложения, таких как PHP PDO например, чтобы оттуда полностью управлять транзакциями.

Рассмотрим практический пример: есть 2 таблицы, пользователи — users и информация о пользователях — user_info. Представим, что нам нужно либо выполнить 3 запроса к базе данных, либо не выполнять их вообще, так как иначе это приведет к сбоям в работе приложения.

В целом я думаю принцип работы транзакции понятен. Но все не так просто. Существуют проблемы параллельных транзакций. Рассмотрим пример. Представим, что во время выполнения этой транзакции, другой пользователь создал вторую параллельную транзакцию и сделал запрос SELECT * FROM user после того, как в нашей транзакции был выполнен первый запрос «INSERT INTO user (id, nik) VALUES (1, ‘nikola’)». Что увидит пользователь второй транзакции? Сможет ли он увидеть вставленную запись даже тогда, когда результаты первой транзакции еще не зафиксировались (не произошел COMMIT)? Или он сможет увидеть изменения только после того, как результаты первой транзакции будут зафиксированы? Оказывается имеют место быть оба варианта. Все зависит от уровня изоляции транзакции.

У транзакций есть 4 уровня изоляции:

  • 0 — Чтение неподтверждённых данных (грязное чтение) (Read Uncommitted, Dirty Read) — самый низкий уровень изоляции. При этом уровне возможно чтение незафиксированных изменений параллельных транзакций. Как раз в этом случае второй пользователь увидит вставленную запись из первой незафиксированной транзакции. Нет гарантии, что незафиксированная транзакция будет в любой момент откачена, поэтому такое чтение является потенциальным источником ошибок.
  • 1 — Чтение подтверждённых данных (Read Committed) — здесь возможно чтение данных только зафиксированных транзакций. Но на этом уровне существуют две проблемы. В этом режиме строки, которые участвуют в выборке в рамках транзакции, для других параллельных транзакций не блокируются, из этого вытекает проблема № 1: «Неповторяемое чтение» (non-repeatable read) — это ситуация, когда в рамках транзакции происходит несколько выборок (SELECT) по одним и тем же критериям, и между этими выборками совершается параллельная транзакция, которая изменяет данные, участвующие в этих выборках. Так как параллельная транзакция изменила данные, результат при следующей выборке по тем же критериям в первой транзакции будет другой. Проблема № 2 — «Фантомное чтение» — этот случай рассмотрен ниже.
  • 2 — Повторяемое чтение (Repeatable Read, Snapshot) — на этом уровне изоляции так же возможно чтение данных только зафиксированных транзакций. Так же на этом уровне отсутствует проблема «Неповторяемого чтения», то есть строки, которые участвуют в выборке в рамках транзакции, блокируются и не могут быть изменены другими параллельными транзакциями. Но таблицы целиком не блокируются. Из-за этого остается проблема «фантомного чтения». «Фантомное чтение» — это когда за время выполнения одной транзакции результат одних и тех же выборок может меняться по причине того, что блокируется не вся таблица, а только те строки, которые участвуют в выборке. Это означает, что параллельные транзакции могут вставлять строки в таблицу, в которой совершается выборка, поэтому два запроса SELECT * FROM table могут дать разный результат в разное время при вставке данных параллельными транзакциями.
  • 3 — Сериализуемый (Serializable) — сериализуемые транзакции. Самый надежный уровень изоляции транзакций, но и при этом самый медленный. На этом уровне вообще отсутствуют какие либо проблемы параллельных транзакций, но за это придется платить быстродействием системы, а быстродействие в большинстве случаев крайне важно.

По умолчанию в MySQL установлен уровень изоляции № 2 (Repeatable Read). И, как я считаю, разработчики MySQL не зря сделали по умолчанию именно этот уровень, так как он наиболее удачный для большинства случаев. С первого раза может показаться, что самый лучший вариант № 3 — он самый надежный, но на практике вы можете испытать большие неудобства из-за очень медленной работы вашего приложения. Помните, что многое зависит не от того, насколько хорош уровень изоляции транзакций в БД, а от того, как спроектировано ваше приложение. При грамотном программировании, можно даже использовать самый низкий уровень изоляции транзакций — все зависит от особенностей структуры и грамотности разработки вашего приложения. Но ненужно стремиться к самому низкому уровню изоляции — нет, просто если вы используйте не самый защищенный режим, следует помнить о проблемах параллельных транзакций, в этом случае вы не растеряетесь и все сделайте правильно.

SET TRANSACTION — этот оператор устанавливает уровень изоляции следующей транзакции, глобально либо только для текущего сеанса.

  • SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL

Существующие соединения не затрагиваются. Для выполнения этого оператора нужно иметь привилегию SUPER. Применение ключевого слова SESSION уста­навливает уровень изоляции по умолчанию всех будущих транзакций только для теку­щего сеанса.

Вы можете также установить начальный глобальный уровень изоляции для сервера mysqld, запустив его с опцией —transaction-isolation

MySQL движки хранения данных

Вольный перевод: MySQL Storage Engines
Автор: Mike Peters

Одна из великолепных возможностей MySQL, отличная от бесплатности, широкой поддержки и быстроты, заключается в выборе различных движков хранения данных (storage engines) для различных таблиц.

MySQL предлагает 7 движков хранения данных, включая «example» — который позволяет Вам реализовать собственную библиотеку хранения.

Что-же такого великолепного в обладании всеми этими вариантами?

Каждый движок хранения данных полностью различен и спроектирован для конкретных нужд приложений.

Не зацикливаясь на одном движке (как Oracle), Вы тем самым можете оптимизировать и выбирать лучший инструмент для своей работы.

Совет: Хорошо спроектированное приложение, активно использующее MySQL, должно использовать различные движки хранения данных для различных таблиц. Если Вы все еще завязли на MyISAM таблицах, может теперь стоит, что-то пересмотреть.

Обзор движков хранения данных MySQL

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

HEAP: Все в памяти. Очень быстрый поиск данных, однако все они хранятся только в памяти и будут потеряны при остановке сервера. Великолепно подходит для временных таблиц.

Archive: Используется для хранения больших объемов данных без индексов, занимая меньший размер.

Merge: Коллекция MyISAM таблиц логически объединенных вместе для единого представления.

InnoDB: Транзакционный тип движка, применяемый при интенсивных операциях записи, спасибо возможности блокировки уровня строк таблицы. Великолепная восстанавливаемость и высокая надежность хранения данных. Движок InnoDB был приобретен Oracle в 2005 году.

NDB: Кластерный движок — данные автоматически разделяются и реплицируются по различным машинам, именуемым — дата узлы. Применяется для приложений, которые требуют высокой производительности с наивысшей степенью доступности. NDB хорошо работает на системах требующих высокой отдачи на операциях чтения. Для «тяжелых» приложений требующих активной записи в конкурирующей среде рассмотрите вариант с InnoDB.

Что-бы лучше понять уникальные характеристики каждого движка хранения данных, посмотрите на эту «магическую» диаграмму:

Примеры:

Ниже приведены несколько примеров использования наиболее подходящих движков хранения для различных задач:

  • Поисковый движок — NDB кластер
  • Логирование веб статистики — Обычные файлы для логирования с оффлайновым обработчиком и записью всей статистики в InnoDB таблицы
  • Финансовые транзакции — InnoDB
  • Сессионные данные — MyISAM или NDB кластер
  • Локальные расчеты — HEAP
  • Словари — MyISAM

Важные замечания по MyISAM таблицам:

  • Таблицы могут быть повреждены. Ежедневно архивируйте Ваши данные или установите еще один MySQL сервер для выполнения репликаций.
  • Включите авто-восстановление (auto-repair) в настройках Вашего сервера (my.cnf):
    myisam-recover=backup,force
    или рассмотрите возможность выполнения ежедневной автоматической проверки таблиц баз данных.
  • Очень быстрое чтение данных (через SELECT)
  • Конкурирующие записи полностью блокируют таблицы. Переключите все, что возможно, на оффлайн обработку записей сериями, что-бы не загружать движок сервера баз данных. (Оффлайн обработка — золотое правило, применимое для всех типов таблиц)
Мастер Йода рекомендует:  Сравнение объектов Java с помощью equals() и hashcode()

Важные замечания по HEAP/Memory таблицам:

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

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

Важные замечания по InnoDB таблицам:

  • Поддержка ACID транзакций. Встроенная отказоустойчивость данных, равная надежности 99.999%. Блокировка уровня строк (сравните с полной блокировкой всей таблицы в MyISAM) означает обеспечение быстрой записи конкурирующих операций.
  • Выполнение «SELECT Count(*) FROM table» без индексов выполняется в InnoDB очень медленно и требует сканирования всей таблицы. (Для MyISAM эта операция ничего не стоит, потому что он хранит внешние записи счетчиков для каждой таблицы).
    Если Вам часто необходима операция «SELECT COUNT(*)» на таблицах InnoDB, создайте MySQL триггер на вставку/удаление, который будет увеличивать/уменьшать счетчик, когда данные добавляются или удаляются из таблицы.
  • Резервирование (бакапирование)
    Простое архивирование всех файлов таблиц для InnoDB невозможно.
    MySQLDump резервирует InnoDB очень медленно. (Если Вы настаиваете на таком резервировании, включите флаг: —opt —compress)
    Быстрое жизнеспособное резервирование, которое так-же может быть использовано как новая «ведомая» (slave) машина, это InnoDB Hot Backup.
  • Восстановление
    В InnoDB встроена поддержка восстановления, которая работает в 99% случаев автоматически. Никогда не трогайте .frm или .ibd файлы в надежде «помочь» восстановлению базы данных. Если встроенное восстановление не сработало, переключайтесь на «ведомый» сервер и восстанавливайте основной из архивов.
  • LOAD DATA INFILE в InnoDB работает очень медленно. Для операций LOAD DATA присмотритесь к использованию MyISAM таблиц.
  • InnoDB меньше, чем MyISAM, прощает выполнение запросов построенных не на индексах. InnoDB отправит Вас в «школу», что-бы быть уверенным, что каждый запрос или обновление будет запущено на индексах. Выполните непроиндексированный запрос и Вы поплатитесь за это временем исполнения.
  • Никогда не изменяйте my.cnf InnoDB лог файл, когда запущен сервер баз данных. Вы разрушите последовательный лог-номер (log sequence number) оставшись без возможность восстановления.
  • Для увеличения производительности InnoDB, присмотритесь к использованию следующих настроек (my.cnf):

    innodb_open_files = 500
    innodb_file_per_table
    innodb_buffer_pool_size = 250M
    innodb_flush_log_at_trx_commit = 2
    innodb_thread_concurrency =8
    innodb_lock_wait_timeout = 500
    interactive_timeout = 20
    back_log = 75
    table_cache = 300
    thread_cache = 32
    thread_concurrency = 8
    wait_timeout = 30
    connect_timeout = 10

Расширяемость

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

Для активно-читающей (read-heavy) среды, используйте NDB кластер или установите репликации для n MyISAM ведомых read-only машин.

Для активно-пишущей (write-heavy) среды, InnoDB с активно/пассивными репликациями будет лучшим типовым решением. Но Вы можете поэкспериментировать с NDB кластером. NDB кластер обычно медленнее чем InnoDB в операциях с активной записью, но он предлагает наивысший уровень доступности.

Транзакции, блокировки, уровни изолированности транзакций в MySQL

С приходом master-master репликаций остро встает вопрос о целостность с достоверностью базы данных.

  • Целостность базы данных — соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам.
  • Достоверность (или истинность) — соответствие фактов, хранящихся в базе данных, реальному миру

При изменении данных, БД переходит от одного состояния к другому, при этом в процессе обновления данных возможны ситуации, когда состояние целостности или достоверности нарушается.

Например:

Прерванный перевод денег со счета на счет, посредством последовательного исполнения двух команд UPDATE, приведет к нарушению целостности:

UPDATE accounts SET money=money-1100 WHERE account=»PC1″; UPDATE accounts SET money=money+1100 WHERE account=»PC2″;

Чтобы избежать подобные ситуации ввели понятие транзакции — атомарного действия над базой, переводящего ее из одного целостного состояния в другое. По сути это последовательность SQL-инструкций, которые должны быть выполнены целиком или отменены.

Механизмы блокировок

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

Если для выполнения некоторой транзакции необходимо, чтобы некоторый объект базы данных не изменялся без ведома этой транзакции, такой объект блокируется.

Основными видами блокировок являются на чтение и на запись:

  • Если клиент хочет читать данные, то другие клиенты тоже могут читать данные, но никто не может записывать, пока первый клиент не закончит чтение (read lock).
  • Если клиент хочет записать данные, то другие клиенты не должны ни читать ни писать эти данные пока первый клиент не закончит (write lock).

Блокировка может быть наложена явно или неявно.

Если клиент не назначает блокировку, MySQL сервер неявно устанавливает необходимый тип блокировки на время выполнения выражения или транзакции. В случае выполнения оператора SELECT сервер установит READ LOCK, а в случае UPDATE — WRITE LOCK. При неявной блокировке уровень блокировки зависит от типа хранилища данных: для MyISAM, MEMORY и MERGE блокируется вся таблица, для InnoDB — только используемые в выражении строки (в случае, если набор этих строк может быть однозначно определен — иначе, блокируется вся таблица).

Часто возникает необходимость выполнения нескольких запросов подряд без вмешательства других клиентов в это время. Неявная блокировка не подходит для этих целей, так как устанавливается только на время выполнения одного запроса. В этом случае клиент может явно назначить, а потом отменить блокировку с помощью выражений LOCK TABLES и UNLOCK TABLES. Явной блокировка всегда блокирует всю таблицу, независимо от механизма хранения.

Изоляция транзакций

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

При параллельном выполнении транзакций возможны следующие проблемы:

1) Потерянное обновление (англ. lost update)

При одновременном изменении одного блока данных разными транзакциями, одно из изменений теряется;

Имеются две транзакции, выполняемые одновременно:

Транзакция 1 Транзакция 2
UPDATE tbl1 SET f2=f2+20 WHERE f1=1; UPDATE tbl1 SET f2=f2+25 WHERE f1=1;

В обеих транзакциях изменяется значение поля f2, при этом одно из изменений теряется. Так что, f2 будет увеличено не на 45, а только на 20 или 25.

Причина:

  1. Первая транзакция прочитала текущее состояние поля.
  2. Вторая транзакция сделала свои изменения, основываясь на своих сохраненных в память данных.
  3. Первая делает обновление поля, используя свои «старые» данные.

2) «Грязное» чтение (англ. dirty read)

Чтение данных, добавленных или изменённых транзакцией, которая впоследствии не подтвердится (откатится);

Транзакция 1 Транзакция 2
SELECT f2 FROM tbl1 WHERE f1=1;
UPDATE tbl1 SET f2=f2+1 WHERE f1=1;
SELECT f2 FROM tbl1 WHERE f1=1;
ROLLBACK WORK;

В транзакции 1 изменяется значение поля f2, а затем в транзакции 2 выбирается значение этого поля. После этого происходит откат транзакции 1. В результате значение, полученное второй транзакцией, будет отличаться от значения, хранимого в базе данных.

3) Неповторяющееся чтение (англ. non-repeatable read)

При повторном чтении в рамках одной транзакции, ранее прочитанные данные оказываются изменёнными.

Предположим, имеются две транзакции, открытые различными приложениями, в которых выполнены следующие SQL-операторы:

Транзакция 1 Транзакция 2
SELECT f2 FROM tbl1 WHERE f1=1; SELECT f2 FROM tbl1 WHERE f1=1;
UPDATE tbl1 SET f2=f2+1 WHERE f1=1;
COMMIT;
SELECT f2 FROM tbl1 WHERE f1=1;

В транзакции 2 выбирается значение поля f2, затем в транзакции 1 изменяется значение поля f2. При повторной попытке выбора значения из поля f2 в транзакции 2 будет получен другой результат. Эта ситуация особенно неприемлема, когда данные считываются с целью их частичного изменения и обратной записи в базу данных.

4) Фантомное чтение (англ. phantom reads)

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

Транзакция 1 Транзакция 2
SELECT SUM(f2) FROM tbl1;
INSERT INTO tbl1 (f1,f2) VALUES (15,20);
COMMIT;
SELECT SUM(f2) FROM tbl1;

В транзакции 2 выполняется SQL-оператор, использующий все значения поля f2. Затем в транзакции 1 выполняется вставка новой строки, приводящая к тому, что повторное выполнение SQL-оператора в транзакции 2 выдаст другой результат. Такая ситуация называется фантомным чтением. От неповторяющегося чтения оно отличается тем, что результат повторного обращения к данным изменился не из-за изменения/удаления самих этих данных, а из-за появления новых (фантомных) данных.

Уровни изоляции

Serializable (упорядочиваемость)

Самый высокий уровень изолированности. Транзакции полностью изолируются друг от друга. Только на этом уровне параллельные транзакции не подвержены эффекту «фантомного чтения».

Repeatable read (повторяемость чтения)

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

Read committed (чтение фиксированных данных)

Завершенное чтение, при котором отсутствует черновое, «грязное» чтение (то есть чтение одним пользователем данных, которые не были зафиксированы в БД командой COMMIT). Тем не менее в процессе работы одной транзакции другая может быть успешно завершена и сделанные ею изменения зафиксированы. В итоге первая транзакция будет работать с другим набором данных. Это проблема неповторяемого чтения.

Read uncommitted (чтение незафиксированных данных)

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

Поведение при различных уровнях изолированности

Сравнение хранилищ данных для MySQL с поддержкой транзакций

Базы данных — это специально разработанное хранилище для различных типов данных. Каждая база данных, имеет определённую модель (реляционная, документно-ориентированная), которая обеспечивает удобный доступ к данным. Системы управления базами данных (СУБД) — специальные приложения (или библиотеки) для управления базами данных различных размеров и форм.

Реляционная система управления базами данных (РСУБД)

СУБД должна обеспечивать реляционную модель работы с данными. Сама модель подразумевает определенный тип связи между сущностями из разных таблиц. Чтобы хранить и работать с данными, такой тип СУБД должен иметь определенную структуру (таблицы). В таблицах каждый столбец может содержать данные разного типа. Каждая запись состоит из множества атрибутов (столбцов) и имеет уникальный ключ, хранящейся в той же таблице — все эти данные взаимосвязаны между собой, как описано в реляционной модели.

Типы данных и отношений между ними

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

При создании структуры таблицы каждое поле записи должно иметь заранее описанный тип (например: строка, целочисленное значение и т.д.). Все СУБД имеют в своем составе различные типы данных, которые не всегда взаимозаменяемы. При работе с СУБД всегда приходится сталкиваться с подобными ограничениями.

Заметка: если вам требуется использовать неструктурированные данные (т.е. записи в одной и той же таблице могут иметь разную структуру), то следует рассмотреть использование NoSQL (безсхемная СУБД).

Популярные и основные реляционные базы данных

В этой статье мы с вами рассмотрим три основных свобоно распространяемых СУБД.

SQLite — очень мощная встраиваемая система управления

MySQL — самая популярная и распространённая СУБД

PostgreSQL — наиболее продвинутая СУБД

Заметка: свободно распространяемое ПО всегда можно изменять под свои нужды. Почти всегда можно свободно получить копию репозитория из системы контроля версий.

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

SQLite

Легко встраиваемая в приложения база данных. Так как это система базируется на файлах, то она предоставляет довольно широкий набор инструментов для работы с ней, по сравнению с сетевыми СУБД. При работе с этой СУБД обращения происходят напрямую к файлам (в эти файлах хранятся данные), вместо портов и сокетов в сетевых СУБД. Именно поэтому SQLite очень быстая, а также мощная благодаря технологиям обслуживающих библиотек.

Типы данных SQLite

  • NULL — значение NULL
  • INTEGER — знаковое целочисленное значение, использует 1, 2, 3, 4, 6, или 8 байт в зависимости от порядка числа
  • REAL — число с плавающей точкой, занимает 8 байт для хранения числа в формате IEEE
  • TEXT — текстовая строка, при хранении используются кодировки UTF-8, UTF-16BE или UTF-16LE
  • BLOB — тип данных BLOB, массив двоичных данных (предназначенный, в первую очередь, для хранения изображений, аудио и видео).

Преимущества SQLite

  • Файловая структура — вся база данных состоит из одного файла, поэтому её очень легко переносить на разные машины
  • Используемые стандарты — хотя может показаться, что эта СУБД примитивная, но она использует SQL. Некоторые особенности опущенны (RIGHT OUTER JOIN или FOR EACH STATEMENT), но основные все-таки поддерживаются
  • Отличная при разработке и тестировании — в процессе разработки приложений часто появляется необходимость масштабирования. SQLite предлагает всё что необходимо для этих целей, так как состоит всего из одного файла и библиотеки написанной на языке C.

Недостатки SQLite

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

Когда использовать SQLite

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

Когда отказаться от SQLite

  • Многопользовательские приложения — если вам необходимо обеспечить доступ к данным для нескольких пользователей, да и к тому же различать их по правам доступа, то, наверное, полноценная СУБД (например: MySQL) будет более логичным выбором
  • Запись больших объемов данных — одно из ограничений SQLite это операции записи. Разрешен только один процесс записи в промежуток времени, что сильно ограничивает производительность.

MySQL

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

Заметка: стоит заметить, что благодаря популярности этой СУБД, существует огромное количество различных плагинов и расширений, облегчающих работу с системой.

Несмотря на то, что в ней не реализован весь SQL функционал, MySQL предлагает довольно много инструментов для разработки приложений. Так как это серверная СУБД, приложения для доступа к данным, в отличии от SQLite работают со службами MySQL.

Типы данных MySQL

  • TINYINT — очень малые целочисленные значения
  • SMALLINT — малые целочисленные значения
  • MEDIUMINT — средние целочисленные значения
  • INT или INTEGER — стандартные целочисленные значения
  • BIGINT — большие целочисленные значения
  • FLOAT — маленькие значения с плавающей точкой (точность до одного значения после точки). Всегда знаковые значения
  • DOUBLE, BOUBLE PRECISION, REAL — Стандартные значения с плавающей точкой. Всегда знаковые
  • DECIMAL, NUMERIC — распакованное значение с плавающей точкой, всегда знаковое.
  • DATE — дата
  • DATETIME — дата и время в одном значении
  • TIMESTAMP — временная отметка timestamp
  • TIME — время
  • YEAR — год, 2 или 4 числа (4 — по-умолчанию)
  • CHAR — строковое значение фиксированной длины, справа всегда добавляются пробелы до указанной длины при сортировке
  • VARCHAR — строковое значение переменной длины
  • TINYBLOB, TINYTEXT — значение типа BLOB или TEXT, 255 (2^8 — 1) символов — максимальныя длина
  • BLOB, TEXT — значение типа BLOB или TEXT, 65535 (2^16 — 1) символов — максимальныя длина
  • MEDIUMBLOB, MEDIUMTEXT — значение типа BLOB или TEXT, 16777215 (2^24 — 1) символов — максимальныя длина
  • LONGBLOB, LONGTEXT — значение типа BLOB или TEXT, 4294967296 (2^32 — 1) символов — максимальныя длина
  • ENUM — перечисление
  • SET — множество

Преимущества MySQL

  • Простота в работе — установить MySQL довольно просто. Дополнительные приложения, например GUI, позволяет довольно легко работать с БД
  • Богатый функционал — MySQL поддерживает большинство функционала SQL.
  • Безопасность — большое количество функций обеспечивающих безопасность, которые поддерживается по умолчанию
  • Масштабируемость — MySQL легко работает с большими объемами данных и легко масштабируется
  • Скорость — упрощение некоторых стандартов позволяет MySQL значительно увеличить производительность.

Недостатки MySQL

  • Известные ограничения — по задумке в MySQL заложены некоторые ограничения функционала, которые иногда необходимы в особо требовательных приложениях.
  • Проблемы с надежностью — из-за некоторых способов обработки данных MySQL (связи, транзакции, аудиты) иногда уступает другим СУБД по надежности.
  • Медленная разработка — Хотя MySQL технически открытое ПО, существуют жалобы на процесс разработки. Стоит заметить, что существуют другие довольно успешные СУБД созданные на базе MySQL, например MariaDB.

Когда следует использовать MySQL

  • распределённые операции — если функционала SQLite не хватает, то стоит рассмотреть MySQL. Так как эта СУБД сочетает в себе продвинутый функционал и свободный доступ к исходному коду.
  • высокий уровень безопасности — система безопасности MySQL включает в себе простые и в то же время достойные способы защиты доступа к данным

  • Веб сайты и веб приложения — большинство сайтов и онлайн приложений спокойно работают с MySQL несмотря на некоторые ограничения. Будучи легкой в настройке и масштабируемой системой — MySQL проверена временем.
  • Индивидуальные решения — если вы работаете с каким либо специфическим проектом, MySQL легко сможет вам помочь благодаря широким возможностям в настройке и функционалом.

Когда лучше отказаться от MySQL

  • Соответствие стандартам -Так как MySQL не ставит для себя целью — полностью соответствовать стандартам SQL, то эта СУБД не полностью поддерживает SQL. Если в будущем вы планируете перейти на подобную систему, то MySQL — не лучший выбор.
  • Многопоточность — хотя некоторые движки БД довольно легко выполняют параллельное чтение, параллельные операции чтения-записи могут создать проблемы
  • Недостаток функционала — некоторые движки MySQL, например, не поддерживают полнотекстовый поиск.

PostgreSQL

PostgreSQL является самым профессиональным из всех трех рассмотренных нами СУБД. Она свободно распространяемая и максимально соответствует стандартам SQL. PostgreSQL или Postgres стараются полностью применять ANSI/ISO SQL стандарты своевременно с выходом новых версий.

От других СУБД PostgreSQL отличается поддержкой востребованного объектно-ориентированного и/или реляционного подхода к базам данных. Например, полная поддержка надежных транзакций, т.е. атомарность, последовательность, изоляционность, прочность (Atomicity, Consistency, Isolation, Durability (ACID).) Благодаря мощным технологиям Postgre очень производительна. Параллельность достигнута не за счет блокировки операций чтения, а благодаря реализации управления многовариантным параллелизмом (MVCC), что также обеспечивает соответствие ACID. PostgreSQL очень легко расширять своими процедурами, которые называются хранимые процедуры. Эти функции упрощают использование постоянно повторяемых операций.

Мастер Йода рекомендует:  Лекция 1. Что такое ASP.NET. Инсталляция и тестовый проект.

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

Обзор возможностей хранилища данных Falcon в MySQL

Хранилище данных Falcon появится в MySQL начиная с версии 5.2 и в будущем, возможно, заменит InnoDB.

Falcon разрабатывается с учетом возможностей современного железа и будет иметь следующую функциональность:
* полная поддержка транзакций (full ACID)
* поддержка ссылочной целостности таблиц
* хранение всех типов данных MySQL
* оптимизации для работы с большим количеством оперативной памяти
* полная мультиверсионность, позволяющая уменьшить, а иногда полностью устранить необходимость в блокировках
* сжатие данных

Re: Обзор возможностей хранилища данных Falcon в MySQL

Re: Обзор возможностей хранилища данных Falcon в MySQL

Расшифруйте для тупого фразу «с учетом возможностей современного железа» — типа тормозить будет больше или просто оптимизацию включат под новые процы или еще там памяти предлагается много жрать? Что имелось ввиду-то?

Re: Обзор возможностей хранилища данных Falcon в MySQL

Т.е. в mysql появится то, что уже с 1812 года есть в PostgreSQL? Нах он (mysql) тогда нужен?

Re: Обзор возможностей хранилища данных Falcon в MySQL

Джим Старки начинает делать из MySQL’я Firebird 😉

Re: Обзор возможностей хранилища данных Falcon в MySQL

Falcon это и есть postgres (MVCC) но только в оперативке, с автоматическим сохранением/загрузкой на диск.

В результате и транзакции и высокая скорость. Но память жрёт, тк не commit’нутые данные писатся на диск даже не пытаются.

Re: Обзор возможностей хранилища данных Falcon в MySQL

Мда. В Oracle задумались: а не пора ли реализовать ли в MySQL то, что в Postgres было 7 лет назад? А в Oracle, Informix, etc, и 12 лет назад?

Re: Обзор возможностей хранилища данных Falcon в MySQL

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

Что-то я не пойму. MySQL будет заниматься оптимизацией доступа к дорожкам веника? Бардаааак.

Re: Обзор возможностей хранилища данных Falcon в MySQL

При чем тут Oracle?

Re: Обзор возможностей хранилища данных Falcon в MySQL

> Что-то я не пойму. MySQL будет заниматься оптимизацией доступа к дорожкам веника? Бардаааак.

Нет. Он просто, по возможности, будет писать данные большими кусками.

Re: Обзор возможностей хранилища данных Falcon в MySQL

> При чем тут Oracle? > VladimirP * (*) (05.02.2007 12:54:53)

В октябре 2005 Oracle прикупил финскую Innobase Oy, которая делает движок InnoDB, на котором сидит MySQL.

Рейзер был прав.

> Что-то я не пойму. MySQL будет заниматься оптимизацией доступа к дорожкам веника? Бардаааак.

«Если вы используете дополнительный слой для хранения данных, у вас просто плохая файловая система.» (Г. Рейзер)

Re: Рейзер был прав.

>»Если вы используете дополнительный слой для хранения данных, у вас просто плохая файловая система.» (Г. Рейзер)

Если Вы бездумно цитируете чужие мысли, значит у вас не хватает своих.

Re: Обзор возможностей хранилища данных Falcon в MySQL

> Falcon это и есть postgres

Falcon делает Джим Старки, который раньше разработал Interbase. Утверждается, что это — новый проект, «с нуля», но в любом случае, идеология будет ближе к интербейсу (с учетом известных его автору грабель) — оно ему роднее, чем постгрес.

Re: Обзор возможностей хранилища данных Falcon в MySQL

Да, MySQL — наше фсио!

Re: Обзор возможностей хранилища данных Falcon в MySQL

> В октябре 2005 Oracle прикупил финскую Innobase Oy, которая делает движок InnoDB, на котором сидит MySQL

Но это не значит, что Оракл будет хоть что-то делать для MySQL.

Зато, в принципе, Оракл может поменять лицензию на InnoDB, и вот тогда Мускулю придется срочно искать новый транзакционный движок. Для того и Falcon, чтобы в луже не оказаться ненароком.

Re: Обзор возможностей хранилища данных Falcon в MySQL

>В результате и транзакции и высокая скорость.

* Serializable isolation levels are not supported.
* Distributed transactions are not supported.
* Lock timeout configuration is not supported.
* Online backup is not supported
* Foreign key support is currently not available.

Re: Обзор возможностей хранилища данных Falcon в MySQL

Оттуда. В Falcon имплементируется версионный механизм. А догадайся какое коренное отличие мускуля от постгреса было?

Re: Обзор возможностей хранилища данных Falcon в MySQL

> * Online backup is not supported > * Foreign key support is currently not available. > Превед!

Да — действительно «превед» .

Re: Обзор возможностей хранилища данных Falcon в MySQL

> Оттуда. В Falcon имплементируется версионный механизм.

А хто тебе сказал, что версионный механизм есть ТОЛЬКО в постгресе. В интербейсе (и во всех его клонах) есть с самого начала, в MS SQL появился недавно.

Re: Обзор возможностей хранилища данных Falcon в MySQL

>А хто тебе сказал, что версионный механизм есть ТОЛЬКО в постгресе.

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

Re: Обзор возможностей хранилища данных Falcon в MySQL

А не проще было бы форкнуть фиребирд?

Re: Обзор возможностей хранилища данных Falcon в MySQL

Сделают и бекап горячий и внешние ключи, наверняка.

А остальное, так ли уж кому надо?

Re: Обзор возможностей хранилища данных Falcon в MySQL

>А не проще было бы форкнуть фиребирд?

Действительно почему всегда изобретать нужно одно и тоже, тем более, AFAIK, Firebird лицензией не пугает никого. MySQL дал бы кластеринг всякие фичи, а Firebird свое хранение, может быть и получилось бы что-то интересное.

Re: Обзор возможностей хранилища данных Falcon в MySQL

> Если раньше мускуль имел репутацию мегабыстрой легкой базы для всякого рода хостингов и прочих хомепаг, он с обрастаниями фичами теряет это преймущество,

Вы чего-то не доглядели — engine MyISAM ни куда не исчезнет, какой движек захотите, такой и используйте

Re: Обзор возможностей хранилища данных Falcon в MySQL

>А остальное, так ли уж кому надо?

Serializable Isolation Level — это самый жестокий уровень транзакций при котором ты гарантировано не получишь интерференции транзакций ни в каком виде. Все остальные допускают влияние друг на друга. http://en.wikipedia.org/wiki/Isolation_(computer_science)

Отсутсвие DTP делает этот движок мертвым для энтерпрайза изначально.

Re: Обзор возможностей хранилища данных Falcon в MySQL

> Firebird свое хранение, может быть и получилось бы что-то интересное.

Firebird’у уже 100 лет как обещают многопоточность, а воз и ныне там, только и отодвигают на следующую версию, плюс проблемы с транзакциями.

Re: Обзор возможностей хранилища данных Falcon в MySQL

>Firebird’у уже 100 лет как обещают многопоточность, а воз и ныне там, только и отодвигают на следующую версию, плюс проблемы с транзакциями.

Я честно говоря думал, что это в версии 2.0 было решено, значит ошибался. Пошел смотреть — еще и лицензий аж 3 штуки фигурируют. Мда.

Re: Обзор возможностей хранилища данных Falcon в MySQL

> Отсутсвие DTP делает этот движок мертвым для энтерпрайза изначально.

Из TFA: «В настоящее время (5.2.0-alpha), хранилище находится в состоянии alpha, т.е. в нем нет всей запланированной функциональности»

Re: Обзор возможностей хранилища данных Falcon в MySQL

В знаете, я сейчас занимаюсь небольшим тестированием MySQL4, MySQL5 и PostgreSQL8.2.

Это песня. Нет, это ПЕСНЯ. Постгрес на основных запросах медленнее MySQL в полтора-два раза.

Но у MySQL по ходу действа проявилась вообще просто потрясающая пенка, от которой жить сразу резко-резко стало скучно-скучно.

Re: Обзор возможностей хранилища данных Falcon в MySQL

В знаете, я сейчас занимаюсь небольшим тестированием MySQL4, MySQL5 и PostgreSQL8.2.

Это песня. Нет, это ПЕСНЯ. Постгрес на основных запросах медленнее MySQL в полтора-два раза.

Но у MySQL по ходу действа проявилась вообще просто потрясающая пенка, от которой жить сразу резко-резко стало скучно-скучно.

Re: Обзор возможностей хранилища данных Falcon в MySQL

>Из TFA: «В настоящее время (5.2.0-alpha), хранилище находится в состоянии alpha, т.е. в нем нет всей запланированной функциональности»

Это можно сказать о любой программе в которой чего-то нет:)

OpenSuSe Linux находится в промежуточной версии 10.2, потому нет запланированного фотошопа:)

Re: Обзор возможностей хранилища данных Falcon в MySQL

В знаете, я сейчас занимаюсь небольшим тестированием MySQL4, MySQL5 и PostgreSQL8.2.

Это песня. Нет, это ПЕСНЯ. Постгрес на основных запросах медленнее MySQL в полтора-два раза.

Но у MySQL по ходу действа проявилась вообще просто потрясающая пенка, от которой жить сразу резко-резко стало скучно-скучно.

Re: Обзор возможностей хранилища данных Falcon в MySQL

>>Из TFA: «В настоящее время (5.2.0-alpha), хранилище находится в состоянии alpha, т.е. в нем нет всей запланированной функциональности»

>Это можно сказать о любой программе в которой чего-то нет:)

Сказать можно всё. Но почему-то не говорили, что, например, MySQL 3.x был альфой из-за того, что в нем не было многоверсионности.

Re: Обзор возможностей хранилища данных Falcon в MySQL

>Но почему-то не говорили, что, например, MySQL 3.x был альфой из-за того, что в нем не было многоверсионности.

Угу. Я пару лет назад читал спеку X/Open DTP (хотел прикрутить JTA с поддержкой XA к своему сторажу) — чето сомневаюсь что поддержка распределенных транзакций такая штука, которую можно добавить в late development — разве что она там уже есть, но недоделана.

Re: Обзор возможностей хранилища данных Falcon в MySQL

> Я пару лет назад читал спеку X/Open DTP (хотел прикрутить JTA с поддержкой XA к своему сторажу)

Разве такие вещи делаются на уровне хранилища данных? Насколько я знаю, это механизм более высокого уровня.

Re: Обзор возможностей хранилища данных Falcon в MySQL

В знаете, я сейчас занимаюсь небольшим тестированием MySQL4, MySQL5 и PostgreSQL8.2.

Это песня. Нет, это ПЕСНЯ. Постгрес на основных запросах медленнее MySQL в полтора-два раза.

Но у MySQL по ходу действа проявилась вообще просто потрясающая пенка, от которой жить сразу резко-резко стало скучно-скучно.

Re: Обзор возможностей хранилища данных Falcon в MySQL

>Разве такие вещи делаются на уровне хранилища данных? Насколько я знаю, это механизм более высокого уровня.

Более. Но движки почему-то то поддерживают, то не поддерживают.

Re: Обзор возможностей хранилища данных Falcon в MySQL

Может, теперь в firefox, наконец, заменят sqlite на mysql? А то lite — не по-пацански как-то.

Re: Обзор возможностей хранилища данных Falcon в MySQL

>Serializable Isolation Level — это самый жестокий уровень транзакций при котором ты гарантировано не получишь интерференции транзакций ни в каком виде. Все остальные допускают влияние друг на друга.

Ну и ладно и хрен с ней 🙂 Но преимущества которые он даёт по сравнению с Read-commited не стоят его недостатков. Хотя бы потому что СУБД может запросто оборвать транзакцию, по причине того что ей не удалось сериализировать (упорядочить) транзакции. Много ли программ имеют настолько продвинутую обработку ошибок, способную повторить всю транзакцию заново?

Ну и ещё один основной недостаток seriazable — это то что все транзакции исполняются последовательно, что попросту запрещает паралеллизм, убивая производительность. Так что уровня следует избегать.

Re: Обзор возможностей хранилища данных Falcon в MySQL

> ещё один основной недостаток seriazable — это то что все транзакции исполняются последовательно, что попросту запрещает паралеллизм

Ты по ссылке-то сходил? «AS IF all transactions in the system had executed serially». На многоверсионнике все транзакции чтения можно исполнять параллельно. С транзакциями записи может быть так и сяк, но «попросту запрещает параллелизм» — это чушь.

Оптимальная организация хранения данных в SQL Server

Несомненно, хранилище данных — один из основных компонентов, определяющих производительность и доступность больших и малых экземпляров SQL Server. В условиях возросших вычислительных возможностей серверов и виртуальных серверов и поддержки объемной памяти хранилища данных и подсистема ввода-вывода могут оказаться узкими местами, снижающими общую пропускную способность

Обеспечиваем доступность и производительность хранилищ данных

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

Данные и файлы журналов

Базовый принцип, который лежит в основе работы SQL Server с хранилищами данных, заключается в том, что базы данных состоят из файлов двух типов:

  • Файлы данных. В этих файлах хранится информация базы данных. Файлы данных SQL Server представляют собой файлы NTFS с расширением. mdf. Простейшая база данных обычно состоит из одного файла данных, но может состоять и из многих файлов данных, находящихся на одном или нескольких дисках.
  • Файлы журналов. В этих файлах хранятся транзакции базы данных, что позволяет восстановить базу данных на определенный момент времени. Файлы журналов транзакций SQL Server представляют собой файлы NTFS с расширением. ldf. В базе данных может быть много файлов журналов, расположенных на одном или нескольких дисках.

Если для создания базы данных используется среда SQL Server Management Studio (SSMS), то файлы данных и журналов хранятся на том же диске по умолчанию. Если не указано иное, то файлы данных и журналов создаются в том же каталоге, что и системные базы данных SQL Server, то есть :\Program Files\Microsoft SQL Server\MSSQL.MSSQLSERVER\MSSQL\DATA. Например, для экземпляра SQL Server 2014, установленного на диске C, файлы данных и журналов по умолчанию будут находиться в каталоге C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA.

Рекомендуется поместить файлы данных и журналов на различные диски. SQL Server записывает все транзакции базы данных в журнал транзакций, поэтому файлы журналов удобно располагать на дисках с высокой скоростью записи. Файлы данных используются для обслуживания запросов и часто должны выполнять множество операций чтения. При создании базы данных можно указать местоположение файлов данных и журналов с помощью команды T-SQL CREATE DATABASE. Чтобы изменить местонахождение существующих файлов данных и журналов, можно запустить команду ALTER DATABASE с параметром MODIFY FILE. В листинге 1 показан пример переноса файла данных базы данных в другое место.

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

И все же AutoGrow следует рассматривать как механизм последнего рубежа защиты. Его не следует использовать в качестве основного метода управления ростом базы данных. Ростом всех файлов данных и журналов следует управлять вручную. Активность базы данных прекращается, когда происходят операции AutoGrow. Частые события AutoGrow — хороший индикатор непредвиденного роста данных. Следующая команда показывает, как установить настройку AutoGrow для файлов данных и журналов:

Почти никогда не рекомендуется активировать функцию AutoShrink для базы данных. Как и операции AutoGrow, операции AutoShrink приводят к остановке всех действий базы данных. Кроме того, администратор не может контролировать время запуска AutoShrink. Использование AutoShrink может привести к спирали операций AutoGrow, а затем AutoShrink, а результатом будет снижение производительности базы данных и чрезмерная фрагментация файлов. Запустить AutoShrink можно с помощью команды:

Еще один полезный прием при работе с хранилищами данных — немедленная инициализация файлов Instant File Initiation. В отличие от большинства рассмотренных в статье параметров, Instant File Initialization управляется политикой Windows Server. Instant File Initialization не обнуляет выделенное пространство для файла, а просто выделяет нужное количество места. SQL Server использует Instant File Initialization во время создания базы данных, AutoGrow и операции восстановления базы данных. Можно включить режим Instant File Initialization на сервере через меню Administrative, чтобы открыть Local Security Policy («Локальная политика безопасности»). Затем разверните Local Policies («Локальные политики») и дважды щелкните на пункте Performance volume maintenance tasks, как показано на экране.

Экран. Включение Instant File Initialization

В результате открывается диалоговое окно свойств Properties для Performance volume maintenance tasks («Выполнение задач по обслуживанию томов»), в котором можно ввести имя учетной записи SQL Server Service.

Хранение данных и уровни RAID

После того, как освоены хранилища SQL Server, можно приступать к изучению следующей важнейшей концепции — уровней RAID, которые можно использовать для дисков в подсистеме хранения данных. Уровни RAID сильно влияют как на производительность, так и на доступность. Как и следовало ожидать, более дорогостоящие варианты, как правило, обеспечивают лучшую производительность и доступность. Наиболее распространенные уровни RAID следующие:

  • RAID 0 (иногда именуется чередованием дисков). На этом уровне RAID данные распределяются между всеми доступными дисками. Он часто используется в различных тестах производительности баз данных. RAID 0 обеспечивает хорошую производительность, но его никогда не следует применять на производственном сервере, так как отказ одного диска приводит к потере данных.
  • RAID 1 (иногда именуется зеркальным отображением дисков). В конфигурации RAID 1 данные отображаются на дисках зеркально. Скорость операций чтения и записи хорошая, но общая емкость дисков уменьшается вдвое. RAID 1 часто используется для файлов журналов SQL Server. В случае отказа одного диска данные не теряются.
  • RAID 5 (иногда именуется чередованием дисков с контролем четности). В конфигурации RAID 5 данные распределяются по нескольким дискам с целью обеспечить избыточность данных. Часто используется для файлов данных. Этот уровень RAID обеспечивает хорошую производительность чтения и устойчив к отказу одного диска. Однако скорость записи невелика.
  • RAID 10 (иногда именуется зеркальным отображением дисков с чередованием). RAID 10 сочетает в себе быстродействие вариантов с чередованием и защиту через зеркальное отображение. RAID 10 обеспечивает самые высокие уровни производительности и доступности среди всех уровней RAID. Для RAID 10 требуется вдвое больше дисков, чем для RAID 5, но конфигурация устойчива к отказу нескольких дисков. Массив RAID 10 продолжает успешно функционировать при отказе половины дисков в наборе. RAID 10 подходит как для файлов данных, так и для журналов.

Tempdb

Еще один важный компонент системы хранения данных SQL Server — tempdb. Это системная база данных SQL Server, которая представляет собой глобальный ресурс, доступный всем пользователям. Tempdb используется для временных объектов пользователя и внутренних операций ядра системы управления базами данных, в том числе объединений, статистической обработки, курсоров, сортировки, хеширования и управления версиями строк. В отличие от данных в типичной пользовательской базе данных, данные в tempdb не сохраняются после отключения экземпляра SQL Server.

Мастер Йода рекомендует:  Юбилей React.js количество звездочек на GitHub у библиотеки превысило 50000

Как правило, tempdb — одна из самых активных баз данных в рабочем экземпляре SQL Server, поэтому следующие рекомендации помогут обеспечить хорошую производительность базы данных SQL Server. Прежде всего, файлы данных и журналов tempdb следует разместить на других физических дисках, нежели файлы журналов и данных рабочей базы данных. По причине очень активного использования tempdb полезно защитить диски, организовав массив RAID 1 или массив RAID 10 с чередованием. Специалисты группы Microsoft SQL Server Customer Advisory Team (SQLCAT) рекомендуют, чтобы в tempdb был один файл данных для каждого ядра процессора. Но эта рекомендация эффективна для очень высоких рабочих нагрузок. Чаще рекомендуется, чтобы отношение файлов данных к ядрам процессора составляло 1:2 или 1:4. Как и в большинстве случаев, это общие рекомендации; оптимальные подходы для конкретной системы могут различаться. Если вы не знаете точно, сколько файлов использовать для tempdb, можно начать с четырех файлов данных. Обычно для tempdb достаточно одного файла журнала. Более подробные рекомендации tempdb вы найдете в материалах, перечисленных во врезке «Учебная литература».

Кроме того, размер tempdb должен быть достаточным, чтобы избежать операций AutoGrow. Как и пользовательские базы данных, tempdb будет испытывать задержки из-за операций AutoGrow. По умолчанию tempdb содержит файл данных в 8 Мбайт, файл журналов в 1 Мбайт и 10% пространства для AutoGrow, а это слишком мало для большинства производственных рабочих нагрузок. Также важно помнить, что при перезапуске SQL Server размер tempdb возвращается к последнему заданному значению.

Размер и перемещения файлов данных и журналов tempdb можно определять с помощью программного кода, приведенного в разделе «Данные и файлы журналов». Запрос в листинге 2 (с сайта MSDN) показывает, как определить размер и процент роста файлов данных и журналов tempdb.

Твердотельные диски

Благодаря нескольким ядрам увеличилась вычислительная мощь, и многие современные системы поддерживают очень большой объем оперативной памяти, из-за чего подсистема ввода-вывода стала узким местом для многих рабочих нагрузок. Традиционные жесткие диски стали более емкими, но быстродействие практически не увеличилось. Проблему можно решить с помощью твердотельных дисков (SSD). Твердотельные диски — сравнительно новая технология хранения данных, которая начала набирать вес на рынке SQL Server в течение последнего года. В прошлом цена устройств SSD была слишком велика, а информационная емкость слишком мала для многих рабочих баз данных. Одна из причин растущей популярности твердотельных дисков — преимущество в производительности перед традиционными жесткими дисками с вращающимся шпинделем. Например, диск Serial Attached SCSI (SAS) с частотой вращения шпинделя 15 000 об/мин может обеспечить пропускную способность 200 Мбайт/с. Для сравнения, SSD-диск Serial ATA (SATA) с 6-Гбайт соединением может обеспечить последовательную пропускную способность около 550 Мбайт/с. Основная причина превосходства SSD-дисков в быстродействии заключается в резком сокращении времени поиска. Когда нужно получить данные с вращающегося жесткого диска, головка должна переместиться в новое место. У SSD-диска нет движущихся частей, поэтому перемещение к новому месту хранения данных определяется быстродействием ячеек памяти.

Твердотельные и быстродействующие флэш-хранилища можно реализовать несколькими способами. Типичное применение — 2,5-дюймовые диски SSD. Эти устройства подключаются напрямую, как хранилища типа DAS, а электронный интерфейс — такой же, как у стандартного жесткого диска. Другая распространенная реализация SSD — в виде плат PCI Express (PCIe), подключаемых непосредственно к системной шине. В этом подходе используются преимущества быстродействующей шины PCIe, чтобы повысить число операций ввода-вывода в секунду (IOPS) и пропускную способность по сравнению со стандартным интерфейсом диска. Кроме того, многие хранилища SAN располагают разделами SSD и функцией автоматического распределения данных по разделам, что позволяет переместить важные рабочие нагрузки на высокопроизводительный раздел SSD, оставляя менее важные рабочие нагрузки на медленных и менее дорогостоящих жестких дисках.

Существуют хранилища SSD различных типов. Среди них — хранилище SSD на основе DRAM и хранилище SSD на основе технологии флэш-памяти, такой как одноуровневые ячейки (SLC) и многоуровневые ячейки (MLC). У каждого типа есть свои достоинства и недостатки.

  • DRAM. Как обычная оперативная память для компьютера, DRAM отличается очень высоким быстродействием, но ненадежна. Для DRAM требуется постоянный элемент питания, чтобы сохранить данные на время отключения данных. Такие хранилища часто выпускаются в виде плат PCIe, устанавливаемых на системной плате сервера.
  • SLC. Быстродействие и жизненный цикл хранилищ на SLC выше, чем у MLC, поэтому SLC используется в хранилищах SSD корпоративного уровня. Однако цена устройств SLC существенно выше, чем у MLC.
  • MLC. Обычно флэш-память типа MLC используется в потребительских устройствах и обходится дешевле, чем SLC. Однако у MLC более низкая скорость операций записи и существенно более высокий износ, чем у SLC.

По быстродействию устройства SSD превосходят жесткие диски с вращающимся шпинделем, но срок их эксплуатации значительно ниже. Приложения с интенсивным вводом-выводом, такие как SQL Server, сокращают срок жизни накопителя SSD. Кроме того, чем больше используемая часть диска, тем меньше продолжительность жизни. Рекомендуется убедиться, что по крайней мере 20% накопителя SSD не занято. Скорость чтения стабильна в течение всего времени эксплуатации устройства. Однако быстродействие при записи в процессе эксплуатации ухудшается, то есть время, необходимое для записи, увеличивается. Важно также помнить, что нет необходимости дефрагментировать диски SSD, потому что метод доступа к данным иной, чем у жестких дисков. В сущности, дефрагментация этого типа дисков приведет только к сокращению их жизненного цикла.

Если нужно использовать диски SSD, не применяйте единственный накопитель SSD и приготовьтесь заменять диски SSD в течение срока эксплуатации сервера. Перечислим возможности применения SSD в SQL Server.

  • Перемещение индексов на диски SSD. Как правило, индексы не очень велики и связаны с интенсивными беспорядочными операциями чтения, поэтому идеально подходят для размещения на дисках SSD.
  • Перемещение файлов данных на диски SSD. С файлами данных обычно связано больше операций чтения, чем записи, поэтому в большинстве случаев они подходят для дисков SSD.
  • Перемещение файлов журналов на диски SSD. Файлы журналов связаны с большим числом операций записи. Поэтому если для файлов журналов применяются диски SSD, используйте диски SSD корпоративного уровня и конфигурации RAID 1 или RAID 10 с зеркальным отображением.
  • Перемещение tempdb на SSD-диск. Как правило, tempdb отличается высоким уровнем неупорядоченных операций записи, что может привести к порче SSD. Поэтому если диски SSD используются для tempdb, то это должны быть SSD корпоративного уровня в конфигурации RAID 1 или RAID 10 с зеркальным отображением, и нужен план замены дисков SSD. Кроме того, обратите внимание на вариант с PCIe DRAM для tempdb. Хранилище DRAM обеспечивает более высокое быстродействие при записи и имеет неограниченный срок эксплуатации. Однако цены хранилищ DRAM могут быть высокими.

Базовые уровни производительности

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

Первая группа счетчиков производительности, которые необходимо отслеживать, представляет собой счетчики, относящиеся к памяти в системном мониторе Windows. Технически это не счетчики хранилища данных, но если памяти недостаточно, то остальные счетчики не имеют значения. Обязательно отслеживайте счетчик Available MBytes объекта Memory. Этот счетчик показывает объем физической памяти, доступной для выделения процессу или системе. Если показатель меньше 100 Мбайт, то полезно увеличить размер памяти. Другой важный счетчик — % Usage объекта Paging File, который показывает используемый объем файла подкачки Windows. Это значение должно быть менее 70%. Если значение выше, то, вероятно, системе требуется больше памяти.

Помимо счетчиков, связанных с памятью Windows, имеется несколько счетчиков производительности хранилища Windows Server. Однако показания этих счетчиков полезны лишь в том случае, если экземпляр SQL Server работает с системой хранения данных с прямым подключением DAS. Если используется SAN, то нужно обращать внимание на метрики производительности SAN.

Если экземпляр SQL Server использует DAS, то в первую очередь убедитесь, что на каждом диске NTFS свободно по крайней мере 20% пространства. Впоследствии можно проверить счетчики хранилища Windows Server с помощью системного монитора. В таблице 1 приведен список нескольких наиболее важных счетчиков; все они связаны с объектом Logical Disk.

SQL Server располагает многочисленными счетчиками производительности, которые помогают управлять экземпляром SQL Server. Некоторые наиболее важные счетчики хранилища SQL Server, показания которых полезно отслеживать, перечислены в таблице 2. Следить за ними можно с помощью системного монитора.

Сохраняем и движемся вперед

Хранилище — высококритичный компонент в производительности базы данных SQL Server. Знание некоторых простых приемов поможет оптимизировать доступность и производительность SQL Server. Более подробные сведения об особенностях хранения данных можно найти в материалах, перечисленных во врезке «Учебная литература».

Учебная литература

    Demystify Tempdb Performance & Management (http://www. >

Листинг 1. Перенос файла данных базы данных в другое место

Листинг 2. Программный код для определения размера и процента роста файлов данных и журналов tempdb

Поделитесь материалом с коллегами и друзьями

SQLite, MySQL и PostgreSQL: сравниваем популярные реляционные СУБД

Реляционные базы данных используются уже очень давно. Они стали популярными благодаря успешным реализациям реляционных моделей в системах управления, оказавшимся весьма удобными для работы с данными. В этой статье мы сравним три самые популярные реляционные системы управления базами данных (РСУБД): SQLite, MySQL и PostgreSQL.

Системы управления базами данных

Базы данных — это логически смоделированные хранилища любых типов данных. Каждая база данных, не являющаяся бессхемной, следует модели, которая задаёт определённую структуру обработки данных. СУБД — это приложения (или библиотеки), управляющие базами данных различных форм, размеров и типов.

Чтобы лучше разобраться в СУБД, ознакомьтесь с этой статьёй.

Реляционные системы управления базами данных

Реляционные системы реализуют реляционную модель работы с данными, которая определяет всю хранимую информацию как набор связанных записей и атрибутов в таблице.

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

Отношения и типы данных

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

Каждый элемент, формирующий запись, должен удовлетворять определённому типу данных (целое число, дата и т.д.). Различные РСУБД используют разные типы данные, которые не всегда взаимозаменяемы.

Такого рода ограничения обычны для реляционных баз данных. Фактически, они и формируют суть отношений.

Популярные РСУБД

В этой статье мы расскажем о 3 наиболее популярных РСУБД:

  • SQLite: очень мощная встраиваемая РСУБД.
  • MySQL: самая популярная и часто используемая РСУБД.
  • PostgreSQL: самая продвинутая и гибкая РСУБД.

SQLite

SQLite — это изумительная библиотека, встраиваемая в приложение, которое её использует. Будучи файловой БД, она предоставляет отличный набор инструментов для более простой (в сравнении с серверными БД) обработки любых видов данных.

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

Поддерживаемые типы данных

  • NULL: NULL-значение.
  • INTEGER: целое со знаком, хранящееся в 1, 2, 3, 4, 6, или 8 байтах.
  • REAL: число с плавающей запятой, хранящееся в 8-байтовом формате IEEE.
  • TEXT: текстовая строка с кодировкойUTF-8, UTF-16BE или UTF-16LE.
  • BLOB: тип данных, хранящийся точно в таком же виде, в каком и был получен.

Note: для получения более подробной информации ознакомьтесь с документацией.

Преимущества

  • Файловая: вся база данных хранится в одном файле, что облегчает перемещение.
  • Стандартизированная: SQLite использует SQL; некоторые функции опущены ( RIGHT OUTER JOIN или FOR EACH STATEMENT ), однако, есть и некоторые новые.
  • Отлично подходит для разработки и даже тестирования: во время этапа разработки большинству требуется масштабируемое решение. SQLite, со своим богатым набором функций, может предоставить более чем достаточный функционал, при этом будучи достаточно простой для работы с одним файлом и связанной сишной библиотекой.

Недостатки

  • Отсутствие пользовательского управления: продвинутые БД предоставляют пользователям возможность управлять связями в таблицах в соответствии с привилегиями, но у SQLite такой функции нет.
  • Невозможность дополнительной настройки: опять-таки, SQLite нельзя сделать более производительной, поковырявшись в настройках — так уж она устроена.

Когда стоит использовать SQLite

  • Встроенные приложения: все портируемые не предназначенные для масштабирования приложения — например, локальные однопользовательские приложения, мобильные приложения или игры.
  • Система доступа к дисковой памяти: в большинстве случаев приложения, часто производящие прямые операции чтения/записи на диск, можно перевести на SQLite для повышения производительности.
  • Тестирование: отлично подойдёт для большинства приложений, частью функционала которых является тестирование бизнес-логики.

Когда не стоит использовать SQLite

  • Многопользовательские приложения: если вы работаете над приложением, доступом к БД в котором будут одновременно пользоваться несколько человек, лучше выбрать полнофункциональную РСУБД — например, MySQL.
  • Приложения, записывающие большие объёмы данных: одним из ограничений SQLite являются операции записи. Эта РСУБД допускает единовременное исполнение лишь одной операции записи.

MySQL

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

Поддерживаемые типы данных

  • TINYINT: очень маленькое целое.
  • SMALLINT: маленькое целое.
  • MEDIUMINT: целое среднего размера.
  • INT или INTEGER: целое нормального размера.
  • BIGINT: большое целое.
  • FLOAT: знаковое число с плавающей запятой одинарной точности.
  • DOUBLE, DOUBLE PRECISION, REAL: знаковое число с плавающей запятой двойной точности.
  • DECIMAL, NUMERIC: знаковое число с плавающей запятой.
  • DATE: дата.
  • DATETIME: комбинация даты и времени.
  • TIMESTAMP: отметка времени.
  • TIME: время.
  • YEAR: год в формате YY или YYYY.
  • CHAR: строка фиксированного размера, дополняемая справа пробелами до максимальной длины.
  • VARCHAR: строка переменной длины.
  • TINYBLOB, TINYTEXT: BLOB- или TEXT-столбец длиной максимум 255 (2^8 – 1) символов.
  • BLOB, TEXT: BLOB- или TEXT-столбец длиной максимум 65535 (2^16 – 1) символов.
  • MEDIUMBLOB, MEDIUMTEXT: BLOB- или TEXT-столбец длиной максимум 16777215 (2^24 – 1) символов.
  • LONGBLOB, LONGTEXT: BLOB- или TEXT-столбец длиной максимум 4294967295 (2^32 – 1) символов.
  • ENUM: перечисление.
  • SET: множества.

Преимущества

  • Простота: MySQL легко устанавливается. Существует много сторонних инструментов, включая визуальные, облегчающих начало работы с БД.
  • Много функций: MySQL поддерживает большую часть функционала SQL.
  • Безопасность: в MySQL встроено много функций безопасности.
  • Мощность и масштабируемость: MySQL может работать с действительно большими объёмами данных, и неплохо походит для масштабируемых приложений.
  • Скорость: пренебрежение некоторыми стандартами позволяет MySQL работать производительнее, местами срезая на поворотах.

Недостатки

  • Известные ограничения: по определению, MySQL не может сделать всё, что угодно, и в ней присутствуют определённые ограничения функциональности.
  • Вопросы надёжности: некоторые операции реализованы менее надёжно, чем в других РСУБД.
  • Застой в разработке: хотя MySQL и является open-source продуктом, работа над ней сильно заторможена. Тем не менее, существует несколько БД, полностью основанных на MySQL (например, MariaDB). Кстати, подробнее о родстве MariaDB и MySQL можно из нашего интервью с создателем обеих РСУБД — Джеймсом Боттомли.

Когда стоит использовать MySQL

  • Распределённые операции: когда вам нужен функционал бо́льший, чем может предоставить SQLite, стоит использовать MySQL.
  • Высокая безопасность: функции безопасности MySQL предоставляют надёжную защиту доступа и использования данных.
  • Веб-сайты и приложения: большая часть веб-ресурсов вполне может работать с MySQL, несмотря на ограничения. Этот инструмент весьма гибок и прост в обращении, что только на руку в длительной перспективе.
  • Кастомные решения: если вы работаете над очень специфичным продуктом, MySQL подстроится под ваши потребности благодаря широкому спектру настроек и режимов работы.

Когда не стоит использовать MySQL

  • SQL-совместимость: поскольку MySQL не пытается полностью реализовать стандарты SQL, она не является полностью совместимой с SQL. Из-за этого могут возникнуть проблемы при интеграции с другими РСУБД.
  • Конкурентность: хотя MySQL неплохо справляется с операциями чтения, одновременные операции чтения-записи могут вызвать проблемы.
  • Недостаток функций: в зависимости от выбора движка MySQL может недоставать некоторых функций.

PostgreSQL

PostgreSQL — это самая продвинутая РСУБД, ориентирующаяся в первую очередь на полное соответствие стандартам и расширяемость. PostgreSQL, или Postgres, пытается полностью соответствовать SQL-стандартам ANSI/ISO.

PostgreSQL отличается от других РСУБД тем, что обладает объектно-ориентированным функционалом, в том числе полной поддержкой концепта ACID (Atomicity, Consistency, Isolation, Durability).

Будучи основанным на мощной технологии Postgres отлично справляется с одновременной обработкой нескольких заданий. Поддержка конкурентности реализована с использованием MVCC (Multiversion Concurrency Control), что также обеспечивает совместимость с ACID.

Хотя эта РСУБД не так популярна, как MySQL, существует много сторонних инструментов и библиотек для облегчения работы с PostgreSQL.

Использование хранилищ NoSQL и реляционных данных для веб-сайта большого объема

Мы создаем крупномасштабный электронный comm-сайт для обслуживания более 100 000 пользователей, но мы ожидаем, что число пользователей быстро вырастет в течение первого года. В общем, сайт функционирует очень похоже на ebay, где пользователи могут создавать, обновлять и удалять списки. Пользователь также может искать списки и приобретать интересующий объект. В принципе, система имеет транзакционные и не транзакционные требования:

Мы хотим использовать возможности масштабируемых хранилищ данных NoSQL на основе документов, таких как Couch или MongoDB, но в то же время нам нужен реляционный магазин для поддержки наших транзакционных требований ACID. Таким образом, мы разработали гибридное решение, которое использует обе технологии.

Поскольку сайт «читается в основном», и, чтобы удовлетворить потребности в масштабируемости, мы создали хранилище данных MongoDB. Для транзакционных потребностей мы настроили кластер MySQL. В качестве компонента промежуточного программного обеспечения мы используем кластер сервера приложений JBoss.

Когда приходит запрос «поиска», JBoss направляет запрос Mongo для обработки поиска, который должен давать очень быстрые результаты, не обременяя MySQL. Когда листинг создается, обновляется, удаляется или приобретается, JBoss обслуживает транзакции против MySQL. Чтобы синхронизировать MongoDB и MySQL, все транзакционные запросы, обработанные JBoss против MySQL, будут включать последний шаг в бизнес-логике, который обновляет соответствующий документ в MongoDB через идентификатор листинга; мы планируем использовать API-интерфейс MongoDB Java, чтобы облегчить эту интеграцию обновления документа.

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

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

Добавить комментарий