Вопрос по дизайну баз данных и middleware

aissp · Сообщение **aissp** » 23 янв 2007, 09:55

Ну тут нечего комментировать бех конкретной цифири. Прграммирование серверов чего бы не говорили теоретики от проектирования и всяческих ООПов=) наука практическая, выше башки не прыгнешь. Главная рекомендация в таких случаях поднять напряжение на ногах процессора и увеличить тактовую частоту:)

Marmot · Сообщение **Marmot** » 23 янв 2007, 10:03

Проф. Преображенский писал(а):Пир-2-пир сеть с монитором синхронизации.

Никогда не слышал про synchronous near real-time writes in peer-to-peer environment.
Там вроде все аsynchronous...

Проф. Преображенский

Marmot писал(а):
Проф. Преображенский писал(а):Пир-2-пир сеть с монитором синхронизации.
Никогда не слышал про synchronous writes in peer-to-peer environment.
Там вроде все аsynchronous...

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

Marmot · Сообщение **Marmot** » 23 янв 2007, 10:20

Проф. Преображенский писал(а):
Marmot писал(а):
Проф. Преображенский писал(а):Пир-2-пир сеть с монитором синхронизации.
Никогда не слышал про synchronous writes in peer-to-peer environment.
Там вроде все аsynchronous...
С синхронной записью, я понял, нет проблем. А вот подтянуть новую базу можно так.

Мне бы детали сюда

, общие слова я тоже умею говорить...

Devil is in details...

aissp · Сообщение **aissp** » 23 янв 2007, 10:33

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

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

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

Однако удачи

Marmot · Сообщение **Marmot** » 23 янв 2007, 10:49

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

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

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

Однако удачи

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

Работа со страничками позволаяет только увеличить скорост. Логика проблемы от этого не меняется. На данный момент мне хочется рассмотреть как можно больше возможных алгоритмов.
Я, к тому же, это все еще и горизонтально скейлить буду...

aissp · Сообщение **aissp** » 23 янв 2007, 11:09

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

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

Сам буду рад услыхать еще способы.

Проф. Преображенский

Marmot писал(а):
Проф. Преображенский писал(а):
Marmot писал(а):
Проф. Преображенский писал(а):Пир-2-пир сеть с монитором синхронизации.
Никогда не слышал про synchronous writes in peer-to-peer environment.
Там вроде все аsynchronous...
С синхронной записью, я понял, нет проблем. А вот подтянуть новую базу можно так.
Мне бы детали сюда , общие слова я тоже умею говорить...
Devil is in details...

Без детальной постановки задачи говорить трудно. Хотя процесс можно представить так:
1. идет синхронная запись.
2. новая база или опоздавшая старая (сбой, перегрузка) выводятся в асинхронный пул. Синхронная запись туда тоже идет.
3. монитор синхронизации выясняет, чего не хватает в базах (как - это другой вопрос). В простейшем случае другая полная база используется как образец.
4. для заполнения рассинхронизированных баз делаются запросы к другим базам.
5. после заполнения пробелов база выводится из асинхронного пула.
Это может быть и не пир2пир. Все можно сделать через монитор синхронизации.

Marmot · Сообщение **Marmot** » 23 янв 2007, 11:23

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

Ну да, за кого ты меня принимаещь

Мы это-то мы уже делаем.
То про что я спрашиваю это только одна из partitions(shards) в нашей системе.
В настоящее время каждый shard состоит из двух серваков с master-to-master replication. Но мы уже приближаемся к приделу производительности на чтение для каждой пары.
Поэтому-то и хотим добавить серваков, не теряя synhronous writes.

Marmot · Сообщение **Marmot** » 23 янв 2007, 11:30

Проф. Преображенский писал(а):1. идет синхронная запись.
2. новая база или опоздавшая старая (сбой, перегрузка) выводятся в асинхронный пул. Синхронная запись туда тоже идет.

Низзяяя, это будут out-of-order writes, например UPDATE записи, которая еще не существует...

Marmot · Сообщение **Marmot** » 23 янв 2007, 11:33

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

А где берут(описан алгоритм) такой монитор синхронизации?

Marmot · Сообщение **Marmot** » 23 янв 2007, 11:36

Проф. Преображенский писал(а): 5. после заполнения пробелов база выводится из асинхронного пула.

Легко сказать, не так просто сделать, апдейты-то не останавливаются...

Проф. Преображенский

Marmot писал(а):
Проф. Преображенский писал(а):1. идет синхронная запись.
2. новая база или опоздавшая старая (сбой, перегрузка) выводятся в асинхронный пул. Синхронная запись туда тоже идет.
Низзяяя, это будут out-of-order writes, например UPDATE записи, которая еще не существует...

Мда. Если это не просто риалтайм регистрация, то контрольные точки и логи спасут.

Проф. Преображенский

Marmot писал(а):
Проф. Преображенский писал(а): 5. после заполнения пробелов база выводится из асинхронного пула.
Легко сказать, не так просто сделать, апдейты-то не останавливаются...

Тонкий момент.

Писать апдейты в лог.

stuard · Сообщение **stuard** » 24 янв 2007, 11:15

А у вас базу какие? Например в оракле есть возможность создания standby сервера с настройкой синхронной записи логов. Когда доставкой логов занимается log writer в этом случае commit происходит только по при успешной записи во все участвующие базы.
Ограничение в том что все standby базы находится в read only режиме.
Также в оракле есть STREAMS. Позволяет это сделать для выбранных объектов.
Есть готовые сервисы для мониторинга транзаций и из синхронной репликации на несколько серверов. Tuxedo вроде как умеет это делать