Только суть кластера - распределение нагрузки, тогда теряется, или тебе кластер ради кластера нужен?
Распределение дисковой и процессорной нагрузки останется даже при использовании двух нод. При этом HA-кластеры также никто не отменял.
- нет поддержки MVCC, те не поддерживается уровень изолированности транзакции "Read committed", принятый по-умолчанию в промышленных СУБД, многосессионность "не нужно"
- нет поддержки полнотекстового поискового индекса
- нет поддержки сжатия данных
- не поддерживаются foreign key
Это всё конечно печально, но в ряде проектов функционал NDB будет достаточен. Функционал внешних ключей можно реализовать триггерами - https://forge.mysql.com/wiki/ForeignKeyS … onstraints
Костыль кнешно, но работать будет возможно даже быстрее, да и не сравнить с MS SQL'ными костылями которые долгое время были единственной альтернативой простого LIMIT'а
Но не о кластерном.
Примеры твитера, фэйсбука, вконтактика и MySQL Cluster'а были приведены для того что бы показать что MySQL используется в серьёзных проектах.
Один луноход с десктопов на кластеры сполз, другой теперь его покрывает.
Дык про "десктопный" Мускул уже вроде как всё решили, поддержка внешних ключей есть как в самом Мускуле, так и в MySQL Workbench. А кластеры - отдельная подтема.
Неактивен
Ты писал про 1 ноду на одном физическом пк, какой смысл кластера тут
А я даже не спорю, что кластер на одной ноде бессмысленнен.
wr224, да даже из одной (хотя что это за кластер тогда smile ):
....
Изначально я говорил про две ноды.
А как на счет того, что сам механизм триггеров влияет на производительность.
Надо смотреть на конкретных задачах.
Используя кластерный NDB storage engine, если в одной сессии будет выполняться вставка (изменение, удаление) строки, то другие сессии, выполняющие выборку из этой же таблицы просто подвиснут в ожидании
NDB использует блокировки строк. Насколько я знаю, в данном случае выборка пройдёт без задержек, если в неё не попадут заблокированные записи.
Редактировался nixadmin (22-02-12 12:38:30)
Неактивен
или берется бесплатный мускуль и начинаются головные боли у разработчика, как бы так спроектировать БД, чтобы компенсировать недочеты опсосного мускуля
Ну Раклы рекомендуют использовать NoSQL и Memcached для OLTP. И как по мне, совет не лишён смысла. Транзакция выполнится быстрее и блокировок на будет.
Неактивен
Неактивен
Неактивен
Это вот это DAO - https://ru.wikipedia.org/wiki/Data_Access_Objects ?
И о какой переносимости может идти речь, если приложение будет жёстко привязано к винде?
Неактивен
И о какой переносимости может идти речь, если приложение будет жёстко привязано к винде?
Обычно в винде говорят о переносимости от винды к винде, чтобы были библиотеки все при себе. Переносить что-то на плафторму с 0,83% пользователей никто не собирается.
Неактивен
при кардинальном изменении API переход от MySQL к какой-то другой СУБД будет невозможен
Скажите, легко ли перейти с MS SQL на Oracle? А если использовать специальные "плюшки" или абстракции (типа того же DAO от MS)?
Обычно в винде говорят о переносимости от винды к винде, чтобы были библиотеки все при себе.
А шо, мускул под win7 и winxp сильно отличается?
Переносить что-то на плафторму с 0,83% пользователей никто не собирается.
1С запилила серверную часть своего продукта под линукс видимо по приколу, от нефиг делать.
MySQL по большей части используется в вебе, а там популярность решений от МС гораздо ниже 50%
Редактировался nixadmin (22-02-12 19:19:22)
Неактивен
ну ты сам понимаешь чем это грозит, если в DAO использован SQL.
Да ничем, надо поменять Storage Engine на NDB со стороны СУБД, и оно сразу заработает. Вероятность возникновения блокировок при чтении не высока, ибо блокировки работают на уровне записи.
А вообще такие переносы в пять минут не делаются. Сначало необходимо оттестить систему на стенде, подготовить среду для переноса и только потом, во время минимальной нагрузки на систему, осуществить перенос.
Неактивен
Чукча не читатель, я же писал уже про то, что уровень изолированности транзакций "read committed" не поддерживается NDB, те существует блокировка на чтение.
Только в том случае, если ты будешь читать запись которую сейчас редактируют/удаляют.
Да и то, можно поиграться с приоритетами на чтение/запись и получить нужную картину.
Вообще это лишняя работа программиста, а проектное время ограничено, сроки
Работа с кластерной СУБД - дополнительный функционал, дополнительный сроки. А вообще, с версии 5.6 MySQL'а будет возможно использовать NoSQL/Memcached и не в кластерном MySQL'е, можно будет один и тот же код использовать на и на одиночном сервере и на кластере.
Неактивен
Но и которую вставляют, записи в таблицу вставляются в произвольном порядке
Я не программист, но всегда думал что если ПК - целое число с автоинкриментом, новыетзаписи будут вставляться именно в конец таблицы и не попадут в выборку до завершения транзакции.
Для оракла например работа с кластером не отличается от работы с одиночным сервером на уровне приложения.
Оракл хорошая СУБД, но цена, как уже писали выше, делает её не привлекательной для ряда проектов. Плюс к тому - сложность развёртывания/обновления.
Если уже написано с помощью SQL, что наиболее вероятно, что тогда делать
Иногда софт надо обновлять. А то получаются ситуации типа софт написан n-лет назад по Win9x, а под современными ОС работает странно.
Неактивен