"?????????? ?????" <***@kamtel.ru> wrote in message news:42ce3bd4$***@news.iks.ru...
Hi!
Post by ÐиклаÑÐµÐ²Ð¸Ñ ÐнÑонDVL> А по существу есть что сказать? Если у тебя получилось, так и
DVL> расскажи, что делал и как сервер настраивал. С техническими
DVL> подробностями.
Постой, давай разберемся - про плохую масштабируемость ты начал говорить -
вот и скажи по существу - аргументируй свои доводы.
Вот есть Oracle Parallel Server вместе с его Distributed Lock Manager.
Не будем говорить, сколько стоит железо и софт для этого. Cache
изначально распределенный на обычном железе, никаких опций
докупать не надо, надо только лицензию ему дать, разрешающую
многосерверность, она просто немного дороже стоит.
Таким образом, несколько серверов обращаются к одной копии базы
данных, разруливая по пути блокировки. Теоретически задержка
должна происходить только если два сервера попытались захватить
одну блокировку. А это зависит только от грамотного проектирования
прикладной системы специально под такую архитектуру. И еще от
задачи. Понятно, что чем больше констрейнов, тем больше неявных
зависимостей. Требование уникальности поля в таблице сразу
накладывает зависимость наличия значения этого поля в строке
от наличия такого-же значения в этого поля в другой строке. В остальных
случаях сервера работают независимо друг от друга. Это очень близко
к тому, что есть в M-технологии. Но в M-технологии используется еще
и ручное управление блокировками. Грамотно расставляя только
необходимые блокировки я могу существенно ослабить зависимости
между параллельными транзакциями. Это примеры слабо связанных
архитектур.
Что может предложить эхотаг? Разбить таблицы на куски и сделать
дистрибъютед вью? И как мне теперь создать уникальное поле
по _всей_ таблице, раскиданной на несколько серверов? А более
сложные констрейны? Например уникальный индекс по нескольким
таблицам? Имеется таблица Parent с полями ID (PK) и Name (VARCHAR)
и таблица Child с полем Name (VARCHAR) и ParentID (FK). Мне нужно,
чтобы конкатенация Parent.Name и Child.Name была уникальна.
В итоге такая архитектура при большинстве транзакций будет
задействовать сразу все сервера с интенсивным трафиком между ними.
Индексы-то оно умеет уникальные раскидывать между серверами?
И нафига тогда все это надо? Уж проще воткнуть процессоров и успокоиться
на SMP архитектуре. Ибо в эхотаге сильно связанная архитектура и в SMP
ей самое место.
Post by ÐиклаÑÐµÐ²Ð¸Ñ ÐнÑонЗнаешь, по Cache тебе сказать ничего не могу - не приходилось. Но много
дисскусий было по этому поводу - не здесь: в rsdn.ru.
Тем нет серъезных дискуссий. Вот в sql.ru жизнь более активна
на тему Cache, но распределенной обработки там тоже
не обсуждается.
Post by ÐиклаÑÐµÐ²Ð¸Ñ ÐнÑÐ¾Ð½Я не сомневаюсь что в
какой-то специфической области он рулит, но не в OLTP точно. То, что
кто-то
там не смог чего-то сделать на Oracle и пр. не говорит еще о том, что на
Oracle, к примеру, нельзя сделать решение более производительное чем на
Cache - может у твоих конкурентов просто не хватило для этого ума.
Может быть и не хватило, но максимум, что они смогли предложить,
так это поставить сановский кластер. То есть пусть заказчик сначала
купит кластер а мы запустим и посмотрим, получилось или нет.
А я просто предложил посмотреть, что из барахла у них не используется.
и мне притащили несколько машин под Win2000 и Linux. Я поставил,
серверную часть, поставил на сотню рабочих машин "эмулятор клиента",
который в фоновом режиме периодически пускал некоторые типичные
транзакции. Померял загрузку процессоров, дисков, сетевой трафик.
Пришел к выводу, что между серверами должен быть свой собственный
сегмент сети, нашли несколько сетевых карт и хаб. Через три дня было
продемонстрировано, что в принципе, полторы тысячи клиентов - реально.
Угадай, какое решение выбрал заказчик?
Post by ÐиклаÑÐµÐ²Ð¸Ñ ÐнÑонЯ
встречал такие решения и на Oracle, и на эхотаге, что волосы дыбом
встают -
плохую программу можно написать на любом языке. Если ты не можешь
подсказать
как это можно реализовать на MS SQL - ты сказал что не получилось, но
объективных причин почему именно нельзя реализовать на MS SQL не назвал,
то
Я называл причины. Ты можешь поставить несколько MS SQL
с одинаковыми базами. Но если они одновременно полезут
в одну таблицу (каждый в свою копию) с модификациями, то
вся твоя репликация (как тут предлагалось) накроется
по определению. Даже если они полезут в разные таблицы,
но связанные констрейном по внешнему ключу. Репликация
при нескольких писателях не бывает.
Post by ÐиклаÑÐµÐ²Ð¸Ñ ÐнÑонКстати, я что-то не припомню ошеломляющих результатов Cache на tpc.org -
эхотаг, Oracle, DB2
А тестов Cache там и нет, ибо это типично реляционные тесты.
Нет смысла сравнивать мерседес с подводной лодкой. Я что-то
нифига не понял, сколько клиентских приложений одновременно
в этих тестах TPC было к серверу подключено? Что они вообще
тестируют? Разруливание сотен конкурирующих транзакций?
Что можно тестировать, когда тебе уже даны готовые таблицы?
При разработке на MUMPS система полностью перепроектируется
по сравнению с аналогичным реляционным решением. Таблицы
там эмулируются сервером приложений, в ядре СУБД таблиц нет.
Выполнение SQL запросов тоже эмулируется сервером приложений.
Оптимизатор SQL там слабоватенький. Это давно известно,
но это никого не огорчает, т.к. SQL-не основной, а скорее,
вспомогательный движок. Это просто надстройка над стандартным
MUMPS. Если поставить подводную лодку на колеса, то трудно
найти ошеломляющие тесты для сравнения с мерседесом.
Эта технология изначально создавалась для распределенной
обработки большого числа конкурирующих транзакций. Необязательно
брать Cache. Можно посмотреть бесплатный (для линукса)
продукт GT.M. http://www.sanchez-gtm.com/
Вообще, разных реализаций MUMPS-систем (M-систем) - как
грязи. Не думаю, что их сильно меньше, чем SQL-систем.
На MUMPS давно есть стандарт ANSI.
С таким-же успехом я могу предложить свои тесты для
своей предметной области, на которых я тестирую СУБД:
Задача 1:
Есть автомобиль, у него есть кузов, четыре колеса и две двери.
Каждая дверь состоит из корпуса и восьми болтов. Каждое
колесо из диска, шины и трех болтов. Болт весит 1 кг, диск - 3 кг,
шина - 2 кг, корпус двери - 11 кг, кузов автомобиля - 31 кг. Нужно
определить массу всех узлов и всего автомобиля.
Имеем таблицу Node:
NodeID, Weight, CalculatedWeight, MaxWeight
болт, 1, 1, NULL
диск, 3, 3, NULL
шина, 2, 2, NULL
колесо, NULL, 8 (1*3+3+2), NULL
корп. дв., 11, 11, NULL
дверь, NULL, 19 (1*8+11), NULL
кузов, 31, 31, NULL
автом., NULL, 101 (8*4+19*2+31), NULL
...и таблицу NodeLink:
ParentID, ChildID, Quantity
автом., кузов, 1
автом., дверь, 2
автом., колесо, 4
дверь, корп. дв., 1
дверь, болт, 8
колесо, диск, 1
колесо, шина, 1
колесо, болт, 3
Weight - заданная масса узла, если она NULL, то ее надо
вычислить на основе массы составных частей. Если узел
не имеет составных частей, то при попытке указать NULL
должна выдаваться ошибка. При попытке удаления
последнего узла из состава, приводящей к неопределенности
массы, тоже должна выдаваться ошибка. Например, если
из состава двери удалить ее корпус и все болты, то окажется,
что у нее нет составных частей и ее заданная масса =NULL.
Сервер должен это отлавливать и выдавать ошибку.
CalculatedWeight - вычисленная масса (если Weight=NULL),
или равная Weight (в противном случае).
MaxWeight - заданное ограничение на вычисленную массу
узла (если NOT NULL). Любые транзакции, приводящие
к превышению лимита массы для какого либо узла,
должны откатываться с соответствующим сообщением
об ошибке.
Quantity - заданное количество дочерних узлов в составе
родительского.
Все числовые значения в общем случае - неотрицательные
вещественные (это тоже должен проверять сервер).
Разумеется, в NodeLink не должно быть возможности
вставки или апдейта записей, приводящих к "закольцовыванию"
структуры. Например, нельзя добавить автомобиль
опять в состав болта. Это тоже должен проверять сервер.
В таблице Node примерно миллион записей, на каждый
узел в среднем 10 входящих линков и 10 исходящих линков,
т.е. в NodeLink всего примерно 10 млн. записей.
Любые поля в обеих таблицах меняют одновременно
100 пользователей.
После решения задачи предложить примерные варианты
действий, если количество пользователей нужно будет
увеличить до 1000 чел.
Задача 2:
Имеем набор выражений, как в электронной таблице:
A=5, B=A+4, C=A*5+B и т.д.
Соответственно есть таблица Variables:
Name, Expression, CurrentValue
A, 5, 5
B, A+4, 9
C, A*5+B, 34
Name - уникальная строка без пробелов (сервер
должен проверять это проверять).
Expression - строка, задает выражение, использует
четыре арифметических действия со скобками. Если
выражение задано некорректно, сервер должен
это отловить.
CurrentValue - вещественное число, вычисленное
значение выражения. Скорость поиска по CurrentValue
очень критична, потому поле должно быть
проиндексировано.
Попытки задания циклов вида А=B+3, а B=A*2 должны
пресекаться. Попытки использования в выражении
отсутствующих в таблице переменных должны пресекаться,
как и попытки удаления из таблицы строк, уже использующихся
в каких-то выражениях. Попытки деления на ноль сервером
должны пресекаться.
В выражении в среднем по пять переменных. Всего в таблице
10 млн. записей.
С таблицей одновременно работают 100 человек. Половина
операций - вставка, изменение, удаление, другая половина -
поиск по вычисляемому полю вида:
SELECT FROM Variables WHERE CurrentValue < 15.
После решения задачи предложить примерные варианты
действий, если количество пользователей нужно будет
увеличить до 1000 чел.
Post by ÐиклаÑÐµÐ²Ð¸Ñ ÐнÑонDVL> рабочих мест. Примерно по 100 транзакций в секунду от каждого
Пишущих?
Нет. Пишущие с каждого рабочего места идут раз в полчаса,
зато сразу пачками по полторы сотни. То есть в среднем
по 1 в 10 секунд (с одного рабочего места). Проблема в том,
что они захватывают большие массивы данных.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73