Pull to refresh
  • by relevance
  • by date
  • by rating

На чём работает digg

MySQL *
Мы уже рассказывали, на чём работает MySpace и как устроены дата-центры Google, а теперь посмотрим на более мелкие проекты, такие как digg. Здесь нет ничего особо уникального и сделанного «по спецзаказу», как в первых двух случаях, но всё равно интересно.

В момент запуска проект размещался на единственном Linux-сервере с Apache 1.3 и PHP 4.x. Для управления базами данных использовались MySQL 4.0, таблицы MyISAM и встроенный поиск MySQL. Разработчики специально старались использовать как можно больше продуктов open source, чтобы гарантировать быстрое развитие проекта без финансовых затруднений. Кроме вышеперечисленных, нашли применение свободные пакеты ImageMagick, Ispell, prototype/scriptaculous и другие. Вскоре к одному серверу добавился другой и начался бурный рост проекта.
Читать дальше →
Total votes 64: ↑63 and ↓1 +62
Views 1.4K
Comments 21

Блокировки в MySQL

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

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


Одновременный доступ нескольких клиентов к хранилищу данных может приводить к ошибкам различного типа. Например, одновременное чтение одним клиентом и запись другим клиентом одной и той же строки таблицы с большой вероятностью приведет к сбою или чтению некорректных данных. Механизмы блокировок позволяют избежать ситуаций одновременного доступа к данным, регламентируя механизм взаимодействия пользователей между собой.
Читать дальше →
Total votes 65: ↑62 and ↓3 +59
Views 95K
Comments 18

Транзакции InnoDB

Lumber room
InnoDB это транзакционный, реляционный движок работающий на основе MySQL сервера. Начиная с 2001 года он поставляется в стандартной сборке, а с версии 5.1 может устанавливаться в качестве плагина (без необходимости перекомпилировать ядро сервера). Синтаксис очень простой.
START TRANSACTION;
...
COMMIT; -- или же ROLLBACK; если что-то пошло в логике не так

Про определение


Определение транзакционности и реляционности значат во-первых значат полноценную связанность таблиц через FK и как следствие — целостность данных при удалении рядов. С MyIsam как известно приходилось вручную удалять связанные данные в нескольких таблицах, в InnoDB — каскадное удаление одним запросом. Во-вторых поскольку для БД немыслимы параллельные версии данных как в SVN и некому эти версии объединять в одну ветку, но при этом необходима параллельная работа нескольких процессов (пользователей) с одними данными, то в качестве решения становится транзакции.
Очередь из запросов-автомобилей теперь пополняется атомарной транзакцией-автобусом. Естественно это плохо, поскольку чем длиней и дольше выполняется транзакция тем больше параллельных процессов будут ждать его. Для ускорения работы создаются остановки — типы и уровни блокировки данных. Для InnoDB по умолчанию это блокирование на уровне строки (по PK), тогда как в MyIsam атомарная операция блокирует всю таблицу.

Читать дальше →
Total votes 13: ↑12 and ↓1 +11
Views 1.7K
Comments 2

Embedded InnoDB новый движок Баз данных

SQL *
Oracle выпустила Embedded InnoDB.
 
Совсем недавно «красный гигант» выпустили Embedded InnoDB, под довольно демократичной лицензией GPLv2, не Апатч 2.0 но тоже сносно.
В данный момент данная БД доступна только для 32-х битных версии Windows и Linux.
Качать и ставить я бы пока не рискнул, сначала хочется осмотреться. Идеться в доку и читается. Так как сегодня на работе мне делать все равно нечего сделаю небольшой обзор-перевод.
Читать дальше →
Total votes 12: ↑9 and ↓3 +6
Views 2.4K
Comments 13

Краткий обзор движков таблиц MySQL

MySQL *
Цель этой статьи — дать краткий, очень сжатый обзор движков, для того, чтобы статьей можно было пользоваться при выборе движка на этапе проектирования \ создания \ оптимизации таблицы. Предполагается, что читатель знает суть вопроса по крайней мере поверхностно и способен сам отыскать всю дополнительную информацию (вопросы в комментах можно задавать всегда :) )
Читать дальше →
Total votes 123: ↑108 and ↓15 +93
Views 67K
Comments 73

A look at MySQL on ZFS

MySQL *
Translation
image

Представляю вниманию общественности перевод достаточно большой статьи об использовании MySQL на ZFS, а так же сравнительное тестирование ZFS и UFS.
Читать дальше →
Total votes 47: ↑43 and ↓4 +39
Views 5.9K
Comments 29

Исправление работы MySQL при поломке innoDB-таблиц

MySQL *
Здравствуйте!
mysql innodb
Я (быть может, как и вы) — разработчик сайтов, и мне, чтобы все мои наработки не потерялись нужен SVN. А так как я работаю не один, то еще, как минимум, и общая БД. Несколько лет назад мы приобрели NAS-сервер Synology DS-101 (Tom`s Guide или Nix), устроили там хранилище, включили базу (правда, MySQL4). Несколько лет служил он нам верой и правдой, пережил приход пьяных электриков (когда нас сначала подключили на 380В, а потом спохватились — почти все погорело), но вот… несколько недель назад база не хотела загружаться. Пришлось исправлять.

Все бы ничего, если бы этот случай не повторился…
Читать дальше →
Total votes 9: ↑8 and ↓1 +7
Views 49K
Comments 11

MongoDB vs MySQL (vs Cassandra): А теперь чуть более правильный ответ

MySQL *
Собственно, сегодня был запощен топик "Сравниваем производительность MongoDB и MySQL на простом примере", в котором указывалось, что MongoDB превышает по производительности MySQL в разы. Хех, когда такое пишут — я сразу лезу проверять и сомневаться. Я полез в исходники оригинального теста (спасибо за публикацию). И как оказалось автор оригинального топика сделал ошибку в три символа и на самом деле не все так:
  1. В оригинале: MongoDB быстрее MySQL пишет в 1.5 раза (ДА, правда у меня в 3 раза)
  2. В оригинале: MongoDB быстрее MySQL читает в 10 раз (НЕТ, на самом деле — MongoDB примерно на равных плюс-минус 10-30%)
  3. InnoDB vs MyISAM — плюс-минус (в оригинале не тестировалось)
Сравнение здесь происходит только как key-value storage (запись-чтение по primary key).


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


А теперь подробнее об ошибке…
Читать дальше →
Total votes 62: ↑56 and ↓6 +50
Views 26K
Comments 71

Как расширение индекса в InnoDB таблицах удивительным образом снижает производительность

MySQL *
Translation
Один из видов оптимизации, который мы часто используем, это расширение индекса. Он подходит, если есть запросы, использующие другие части составного ключа. И обычно это безопасно, но есть некоторые случаи, где производительность катастрофически падает.

Рассмотрим пример.
Читать дальше →
Total votes 71: ↑68 and ↓3 +65
Views 3.9K
Comments 61

[Перевод] Разделение JVM на платную/бесплатную версии: истерия, начавшаяся с поста в твиттере

Java *
В продолжение топика Oracle намеревается разделить JVM На платную/бесплатную версии

pelegri, редактор известнейшего блога о Java и иже — The Aquarium, отписался про ту истерии, которая началась после заявления представителя Oracle относительно Premium-версии JVM.

Мой вольный перевод со вставками необходимых ссылок ниже.

Читать дальше →
Total votes 52: ↑44 and ↓8 +36
Views 901
Comments 16

Полнотекстовый поиск в InnoDB

MySQL *
Sandbox
Привет, Хабрачитатель!
Полнотекстовый поиск данных в InnoDB – это известная головная боль многих разработчиков под MySQL / InnoDB. Для тех, кто не в курсе дела я объясню. В типе таблиц MyISAM есть полноценный полнотекстовый поиск данных, однако сама таблица исторически имеет ограничения, которые являются принципиальными в отдельных проектах. В более «продвинутом» типе таблиц InnoDB полнотекстового поиска нет. Вот и приходится мириться бедным разработчикам либо с ограничениями MyISAM, либо с отсутствием поиска в InnoDB. Я хочу рассказать о том, какие есть способы организовать полноценный поиск в InnoDB без магии и исключительно штатными средствами. Также будет интересно сравнить скоростные характеристики каждого способа.
Читать дальше →
Total votes 79: ↑73 and ↓6 +67
Views 35K
Comments 55

Строгий режим MySQL и почему он должен быть включен

MySQL *
В MySQL есть такой специальный режим, предназначенный для введения в базу неправильных данных. Например, чтобы вместо 20000000000 вставлять в INT-поле 2147483647. Или наполнять базу несуществующими датами. Или обрезанными строками. Ну или мало ли для чего этот режим может тебе пригодится.

Режим этот называется «обычный режим».

WTF?
Total votes 98: ↑83 and ↓15 +68
Views 35K
Comments 42

MySQL сможет работать как NoSQL сервер

NoSQL *
В экспериментальной версии (5.6.2) Oracle mysql появился плагин, позволяющий обращаться к innodb или ndb (mysql cluster) данным через memcached интерфейс. Оставляя возможность доступа к тем же данным через sql интерфейс.

Описание здесь:
Сообщение Оракла
http://blogs.innodb.com/wp/2011/04/nosql-to-innodb-with-memcached/

Код:
http://labs.mysql.com/
Total votes 46: ↑42 and ↓4 +38
Views 2.9K
Comments 57

Google открывает LevelDB: ещё одна внутренняя разработка

NoSQL *
Компания Google открыла исходные коды LevelDB — это созданный в Google быстрый движок (библиотека) для работы с хранилищем пар ключ-значение.

Библиотеку LevelDB на C++ можно использовать для разных целей. Например, веб-браузер может обрабатывать с помощью LevelDB кэш недавно посещённых страниц. Операционная система — список установленных пакетов и зависимостей между ними, а любое приложение может использовать LevelDB для хранения пользовательских настроек.
Читать дальше →
Total votes 49: ↑41 and ↓8 +33
Views 12K
Comments 34

8123 байта хватит каждому

MySQL *
Сегодня во время перевода одного сайта с таблиц MyISAM на InnoDB, у последних выяснилась одна интересна особенность. Запрос на изменение движка для двух таблиц возвращал странную ошибку «Got error 139 from storage engine». После поиска информации на эту тему, было выяснено, что данная ошибка возникает тогда, когда какая-либо строка таблицы не вмещается в половину страницы памяти, с которыми работает MySQL. Страницы эти равны 16 Кб, а половина, стало быть, 8 Кб.

Само по себе ограничение довольно странное, но на первый взгляд кажется трудно достижимым, ведь как известно, MySQL хранят текстовые данные в хранилище, отдельном от табличных строк. Оказалось, что это верно только на половину. На самом деле InnoDB хранит в отдельном хранилище только «излишки», к коим он не относит первые 768 байтов каждого текстового поля. Т.е. любой текст будет отъедать от длины строки столько байт, сколько он содержит, но не больше 768. Несложно подсчитать, что максимальное число текстовых полей длиной от 768 байт, которое можно безопасно хранить в одной таблице — 10. И действительно, если запустить пример, все пройдет гладко. Но стоит увеличить количество полей хотя бы на одно, и мы получим ту же ошибку, что и в начале.
Читать дальше →
Total votes 82: ↑75 and ↓7 +68
Views 10K
Comments 27

Основные тезисы конференции HighLoad++ 2011

Self Promo
imageВ октябре 2011 года в Москве проходила ежегодная конференция разработчиков высоконагруженных проектов HighLoad++.
Решил поделиться с читателями основными тезисами с конференции. Поскольку вся информация открыта и доступна на странице конференции, решил что собрать все тезисы вместе будет не такой уж и плохой затеей. Сразу отмечу, что в отчёте не содержится детальной информации о каждом докладе — затронуты лишь ключевые моменты.
Итак, о чём говорилось на HighLoad++ 2011.
Читать дальше →
Total votes 32: ↑30 and ↓2 +28
Views 3.9K
Comments 2

Оптимизация запросов MySQL с использованием пользовательских переменных

MySQL *
Sandbox
Введение. В современном мире существует большое количество задач, в рамках которых приходится обрабатывать большие массивы однотипных данных. Яркими примерами являются системы для анализа биржевых котировок, погодных условий, статистики сетевого трафика. Многие из этих систем используют различные реляционные базы данных, в таблицах которых содержатся такие объемы данных, что правильное составление и оптимизация запросов к этим таблицам становится просто необходимым для нормального функционирования системы. В этой статье описаны методы решения ( и сравнительные временные характеристики используемых методов ) нескольких задач по получению данных из таблиц СУБД MySQL, содержащих статистику о проходящем через маршрутизаторы одного из крупных российских сетевых провайдеров сетевом трафике. Интенсивность потока данных, поступающего с главного маршрутизатора такова, что ежесуточно в таблицы базы данных используемой системы мониторинга сетевого трафика поступает в среднем от 400 миллионов до миллиарда записей, содержащих информацию о транзакциях TCP/IP (рассматриваемый маршрутизатор экспортирует данные по протоколу netflow). В качестве СУБД для системы мониторинга используется MySQL.
Читать дальше →
Total votes 82: ↑74 and ↓8 +66
Views 63K
Comments 19

mysqlcheck и optimize таблиц InnoDB

Lumber room
Только что заметил, что если делать
mysqlcheck -o --repair db_name
и ваши таблицы в InnoDB, то не только не происходит repair (что и не должно, так как движок не поддерживает эту функцию), но и optimize не срабатывает.
То есть, база остается без optimize и вы этого не замечаете!

Если делать так:
mysqlcheck -o db_name
, то происходит пересоздание (recreate) каждой таблицы.

Из-за этого у меня optimize не выполнялся скриптом по крону уже полгода, с момента перехода с MyISAM на InnoDB.

PS: В моем случае используется innodb_file_per_table.
Total votes 15: ↑6 and ↓9 -3
Views 2.1K
Comments 5

Кластерные и «обычные» индексы MySQL (InnoDB)

MySQL *
Sandbox
Все мы помним хрестоматийное объяснение «что такое индексы в БД и как они облегчают задачи поиска нужных строк». Уверен, у большинства из вас перед глазами встаёт нечто подобное:

Некластерный индекс

И сразу становится очевидно, насколько меньше данных нужно перелопатить для поиска двух-трёх нужных строк. Гениально. Просто. Понятно.

И лично мне всегда казалось, что улучшать эту схему некуда… Пока я не познакомился с кластерными индексами. Оказалось, что всё не так уж радужно с «обычными» индексами.

Итак, что же такое кластерный индекс, чем он лучше некластерного, и как с ним обстоит дело у MySQL.
Читать дальше →
Total votes 90: ↑87 and ↓3 +84
Views 90K
Comments 33

Практическая оптимизация и масштабируемость MySQL InnoDB на больших объёмах данных

MySQL *
Данный пост не будет рассказывать про индексы, планы запросов, триггеры для построения агрегатов и прочие общие способы оптимизации запросов и структуры БД. Так же не будет рассказывать про оптимальные настройки с префиксом innodb_. Возможно прочитав текст ниже вы лучше поймёте смысл некоторых из них. В данном посте речь пойдёт об InnoDB и его функционирование.

Какие проблемы может помочь решить этот пост?


  • Что делать если у вас в списке процессов множественные селекты которым казалось бы никто не мешает?
  • Что делать если всё хорошо настроено, запросы пролетают как ракеты и список процессов постоянно пустой, но на сервере высокий LA и запросы начинают работать немного медленнее, ну например вместо 100мс получается 500мс ?
  • Как быстро масштабировать систему, когда нет возможности всё переделать?
  • У вас коммерческий проект в конкурентной среде и проблему надо решать немедленно?
  • Почему один и тот же запрос работает то быстро то медленно?
  • Как организовать быстрый кеш и поддерживать его в актуальном состояние?

Читать дальше →
Total votes 45: ↑39 and ↓6 +33
Views 18K
Comments 46