Как облажался MySQL

petrun · 21-02-12 23:17:24

MOP3E пишет:

Ыыыыы! С чего, собственно, и стартовала данная тема.

В одном из движков. Или чукча не читатель?

MOP3E пишет:

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

У вас поразительное свойство, объявлять все что вам не подходит и(или) к чему вы не удосужились прочитать доку кривой поделкой.

MOP3E · 21-02-12 23:22:08

petrun пишет:

В одном из движков. Или чукча не читатель?

Скажу точнее:
В одном из движков поддержка внешних ключей есть. В другом - есть поддержка кластеров. Внешние ключи на кластерах с MySQL не поддерживаются. А чукча, да - он не читатель. Так что не будь чукчей - иди и прочитай!

petrun пишет:

У вас поразительное свойство, объявлять все что вам не подходит и(или) к чему вы не удосужились прочитать доку кривой поделкой.

У меня поразительное свойство - не обращать абсолютно никакого внимания на пропаганду пенгванутых.

petrun · 22-02-12 00:22:46

MOP3E пишет:

Внешние ключи на кластерах с MySQL не поддерживаются.

Вы в первой теме что, про кластеры писали?

MOP3E пишет:

У меня поразительное свойство - не обращать абсолютно никакого внимания на пропаганду пенгванутых.

Господи, где вы пропаганду мускуля увидели?

MOP3E · 22-02-12 03:04:33

petrun пишет:

Вы в первой теме что, про кластеры писали?

Один луноход с десктопов на кластеры сполз, другой теперь его покрывает. Круговая порука, однако!

petrun пишет:

Господи, где вы пропаганду мускуля увидели?

У тебя есть что по теме сказать? Или пора тебе предупреждение ставить за переход на личности?

nixadmin · 22-02-12 06:22:45

wr224 пишет:

Только суть кластера - распределение нагрузки, тогда теряется, или тебе кластер ради кластера нужен?

Распределение дисковой и процессорной нагрузки останется даже при использовании двух нод. При этом HA-кластеры также никто не отменял.

wr224 пишет:

- нет поддержки MVCC, те не поддерживается уровень изолированности транзакции "Read committed", принятый по-умолчанию в промышленных СУБД, многосессионность "не нужно"
- нет поддержки полнотекстового поискового индекса
- нет поддержки сжатия данных
- не поддерживаются foreign key

Это всё конечно печально, но в ряде проектов функционал NDB будет достаточен. Функционал внешних ключей можно реализовать триггерами - forge.mysql.com/wiki/ForeignKeySupport# … onstraints
Костыль кнешно, но работать будет возможно даже быстрее, да и не сравнить с MS SQL'ными костылями которые долгое время были единственной альтернативой простого LIMIT'а lol

MOP3E пишет:

Но не о кластерном.

Примеры твитера, фэйсбука, вконтактика и MySQL Cluster'а были приведены для того что бы показать что MySQL используется в серьёзных проектах.

MOP3E пишет:

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

Дык про "десктопный" Мускул уже вроде как всё решили, поддержка внешних ключей есть как в самом Мускуле, так и в MySQL Workbench. А кластеры - отдельная подтема.

wr224 · 22-02-12 09:56:10

nixadmin пишет:

Распределение дисковой и процессорной нагрузки останется даже при использовании двух нод.

Ты писал про 1 ноду на одном физическом пк, какой смысл кластера тут

nixadmin пишет:

Это всё конечно печально, но в ряде проектов функционал NDB будет достаточен. Функционал внешних ключей можно реализовать триггерами - forge.mysql.com/wiki/ForeignKeyS … onstraints
Костыль кнешно, но работать будет возможно даже быстрее, да и не сравнить с MS SQL'ными костылями которые долгое время были единственной альтернативой простого LIMIT'а

А как на счет того, что сам механизм триггеров влияет на производительность. Про многосессионные OLTP системы ты, как я понимаю, скромно умалчиваешь, а ведь в этом основной затык, сейчас многое сервера приложений создают пул соединений с СУБД. Используя кластерный NDB storage engine, если в одной сессии будет выполняться вставка (изменение, удаление) строки, то другие сессии, выполняющие выборку из этой же таблицы просто подвиснут в ожидании

nixadmin · 22-02-12 11:37:53

wr224 пишет:

Ты писал про 1 ноду на одном физическом пк, какой смысл кластера тут

А я даже не спорю, что кластер на одной ноде бессмысленнен.

nixadmin пишет:

wr224, да даже из одной (хотя что это за кластер тогда smile ):
....

Изначально я говорил про две ноды.

wr224 пишет:

А как на счет того, что сам механизм триггеров влияет на производительность.

Надо смотреть на конкретных задачах.

wr224 пишет:

Используя кластерный NDB storage engine, если в одной сессии будет выполняться вставка (изменение, удаление) строки, то другие сессии, выполняющие выборку из этой же таблицы просто подвиснут в ожидании

NDB использует блокировки строк. Насколько я знаю, в данном случае выборка пройдёт без задержек, если в неё не попадут заблокированные записи.

Отредактировано nixadmin (22-02-12 11:38:30)

wr224 · 22-02-12 11:56:00

nixadmin пишет:

А я даже не спорю, что кластер на одной ноде бессмысленнен.

nixadmin пишет:

Изначально я говорил про две ноды.

Да и на 2х он бессмыслен по большому то счету

nixadmin пишет:

Надо смотреть на конкретных задачах.

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

nixadmin пишет:

NDB использует блокировки строк. Насколько я знаю, в данном случае выборка пройдёт без задержек, если в неё не попадут заблокированные записи.

А если попадут, тогда получим затык, что недопустимо на OLTP системах. Те получается 2 варианта - или покупается нормальная СУБД, или берется бесплатный мускуль и начинаются головные боли у разработчика, как бы так спроектировать БД, чтобы компенсировать недочеты опсосного мускуля, любителям линуха и гемороя конечно предпочтительней второй вариант, правда можно так остаться без работы

nixadmin · 22-02-12 12:24:40

wr224 пишет:

или берется бесплатный мускуль и начинаются головные боли у разработчика, как бы так спроектировать БД, чтобы компенсировать недочеты опсосного мускуля

Ну Раклы рекомендуют использовать NoSQL и Memcached для OLTP. И как по мне, совет не лишён смысла. Транзакция выполнится быстрее и блокировок на будет.

dev.mysql.com/tech-resources/articles/m … .2-ga.html

wr224 · 22-02-12 12:53:02

nixadmin пишет:

Ну Раклы рекомендуют использовать NoSQL и Memcached для OLTP.

Ораклы рекомендуют использовать свой продукт, вообще чудесно, напрочь лишаем приложение переносимости и простоты поддержки, запихав в него Memcached API вместо SQL

nixadmin · 22-02-12 12:59:27

Переносимости куда? Что мне мешает использовать Memcached на другой системе?

wr224 · 22-02-12 13:06:17

nixadmin пишет:

Переносимости куда? Что мне мешает использовать Memcached на другой системе?

Например на другую БД

nixadmin · 22-02-12 13:31:53

Что бы обеспечить переносимость "Например на другую БД" нужно использовать только ANSI SQL, а это лишит многих плющек специфичных для той-или иной СУБД (про LIMIT'ы в этой теме уже писали).

wr224 · 22-02-12 16:02:15

nixadmin пишет:

Что бы обеспечить переносимость "Например на другую БД" нужно использовать только ANSI SQL, а это лишит многих плющек специфичных для той-или иной СУБД (про LIMIT'ы в этой теме уже писали).

Эти специфические, как ты их назвал, "плюшки", используются редко, а вот в твоем случае придется переписывать все DAO, вы, луноходы, обожаете жопой крутить

nixadmin · 22-02-12 16:35:06

Это вот это DAO - ru.wikipedia.org/wiki/Data_Access_Objects ?

И о какой переносимости может идти речь, если приложение будет жёстко привязано к винде?

Babusha · 22-02-12 17:12:48

nixadmin пишет:

И о какой переносимости может идти речь, если приложение будет жёстко привязано к винде?

Обычно в винде говорят о переносимости от винды к винде, чтобы были библиотеки все при себе. Переносить что-то на плафторму с 0,83% пользователей никто не собирается.

MOP3E · 22-02-12 17:23:20

nixadmin пишет:

И о какой переносимости может идти речь, если приложение будет жёстко привязано к винде?

DAO - Data Access Objects - объекты доступа к данным. Если абстрагироваться от технологий Майкрософта, будет понятно, что при кардинальном изменении API переход от MySQL к какой-то другой СУБД будет невозможен. Такие дела...

nixadmin · 22-02-12 18:18:42

MOP3E пишет:

при кардинальном изменении API переход от MySQL к какой-то другой СУБД будет невозможен

Скажите, легко ли перейти с MS SQL на Oracle? А если использовать специальные "плюшки" или абстракции (типа того же DAO от MS)?

Babusha пишет:

Обычно в винде говорят о переносимости от винды к винде, чтобы были библиотеки все при себе.

А шо, мускул под win7 и winxp сильно отличается?

Babusha пишет:

Переносить что-то на плафторму с 0,83% пользователей никто не собирается.

1С запилила серверную часть своего продукта под линукс видимо по приколу, от нефиг делать.
MySQL по большей части используется в вебе, а там популярность решений от МС гораздо ниже 50% smile

Отредактировано nixadmin (22-02-12 18:19:22)

wr224 · 22-02-12 18:33:02

nixadmin пишет:

Это вот это DAO - ru.wikipedia.org/wiki/Data_Access_Objects ?
И о какой переносимости может идти речь, если приложение будет жёстко привязано к винде?

Понятно, в программировании ты 0, вот это ru.wikipedia.org/wiki/Data_Access_Object. Да с переносимостью на другую СУБД я загнул, давай проще - у меня к примеру есть одиночный сервер MySQL, начала проседать производительность, решил перенести на кластер, ну ты сам понимаешь чем это грозит, если в DAO использован SQL. Надеюсь до тебя доходит о чем я говорю

nixadmin · 22-02-12 18:49:33

wr224 пишет:

ну ты сам понимаешь чем это грозит, если в DAO использован SQL.

Да ничем, надо поменять Storage Engine на NDB со стороны СУБД, и оно сразу заработает. Вероятность возникновения блокировок при чтении не высока, ибо блокировки работают на уровне записи.

А вообще такие переносы в пять минут не делаются. Сначало необходимо оттестить систему на стенде, подготовить среду для переноса и только потом, во время минимальной нагрузки на систему, осуществить перенос.

wr224 · 22-02-12 19:03:02

nixadmin пишет:

Да ничем, надо поменять Storage Engine на NDB со стороны СУБД, и оно сразу заработает. Вероятность возникновения блокировок при чтении не высока, ибо блокировки работают на уровне записи.
А вообще такие переносы в пять минут не делаются. Сначало необходимо оттестить систему на стенде, подготовить среду для переноса и только потом, во время минимальной нагрузки на систему, осуществить перенос.

Чукча не читатель, я же писал уже про то, что уровень изолированности транзакций "read committed" не поддерживается NDB, те существует блокировка на чтение. Вообще это лишняя работа программиста, а проектное время ограничено, сроки

Отредактировано wr224 (22-02-12 19:06:32)

nixadmin · 22-02-12 19:36:03

wr224 пишет:

Чукча не читатель, я же писал уже про то, что уровень изолированности транзакций "read committed" не поддерживается NDB, те существует блокировка на чтение.

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

wr224 пишет:

Вообще это лишняя работа программиста, а проектное время ограничено, сроки

Работа с кластерной СУБД - дополнительный функционал, дополнительный сроки. А вообще, с версии 5.6 MySQL'а будет возможно использовать NoSQL/Memcached и не в кластерном MySQL'е, можно будет один и тот же код использовать на и на одиночном сервере и на кластере.

wr224 · 22-02-12 20:14:50

nixadmin пишет:

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

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

nixadmin пишет:

Работа с кластерной СУБД - дополнительный функционал, дополнительный сроки. А вообще, с версии 5.6 MySQL'а будет возможно использовать NoSQL/Memcached и не в кластерном MySQL'е, можно будет один и тот же код использовать на и на одиночном сервере и на кластере.

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

petrun · 22-02-12 22:07:44

Я что-то вообще не пойму о чем вся тема. О что что мускуль не универсальная замена ораклу или db2 что ли?

nixadmin · 23-02-12 07:08:03

wr224 пишет:

Но и которую вставляют, записи в таблицу вставляются в произвольном порядке

Я не программист, но всегда думал что если ПК - целое число с автоинкриментом, новыетзаписи будут вставляться именно в конец таблицы и не попадут в выборку до завершения транзакции.

wr224 пишет:

Для оракла например работа с кластером не отличается от работы с одиночным сервером на уровне приложения.

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

wr224 пишет:

Если уже написано с помощью SQL, что наиболее вероятно, что тогда делать

Иногда софт надо обновлять. А то получаются ситуации типа софт написан n-лет назад по Win9x, а под современными ОС работает странно.

Форум StopLinux

Объявление

#76 21-02-12 23:17:24

Re: Как облажался MySQL

#77 21-02-12 23:22:08

Re: Как облажался MySQL

#78 22-02-12 00:22:46

Re: Как облажался MySQL

#79 22-02-12 03:04:33

Re: Как облажался MySQL

#80 22-02-12 06:22:45

Re: Как облажался MySQL

#81 22-02-12 09:56:10

Re: Как облажался MySQL

#82 22-02-12 11:37:53

Re: Как облажался MySQL

#83 22-02-12 11:56:00

Re: Как облажался MySQL

#84 22-02-12 12:24:40

Re: Как облажался MySQL

#85 22-02-12 12:53:02

Re: Как облажался MySQL

#86 22-02-12 12:59:27

Re: Как облажался MySQL

#87 22-02-12 13:06:17

Re: Как облажался MySQL

#88 22-02-12 13:31:53

Re: Как облажался MySQL

#89 22-02-12 16:02:15

Re: Как облажался MySQL

#90 22-02-12 16:35:06

Re: Как облажался MySQL

#91 22-02-12 17:12:48

Re: Как облажался MySQL

#92 22-02-12 17:23:20

Re: Как облажался MySQL

#93 22-02-12 18:18:42

Re: Как облажался MySQL

#94 22-02-12 18:33:02

Re: Как облажался MySQL

#95 22-02-12 18:49:33

Re: Как облажался MySQL

#96 22-02-12 19:03:02

Re: Как облажался MySQL

#97 22-02-12 19:36:03

Re: Как облажался MySQL

#98 22-02-12 20:14:50

Re: Как облажался MySQL

#99 22-02-12 22:07:44

Re: Как облажался MySQL

#100 23-02-12 07:08:03

Re: Как облажался MySQL

Подвал форума