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

Marmot · Сообщение **Marmot** » 24 янв 2007, 13:29

stuard писал(а):А у вас базу какие?

MySQL у нас

stuard писал(а): Например в оракле есть возможность создания standby сервера с настройкой синхронной записи логов. Когда доставкой логов занимается log writer в этом случае commit происходит только по при успешной записи во все участвующие базы.
Ограничение в том что все standby базы находится в read only режиме.

Нах мне SPOF в виде log writer-а

или он не SPOFится? Да и не принципиально это, а вот...

stuard писал(а):
Также в оракле есть STREAMS. Позволяет это сделать для выбранных объектов.
Есть готовые сервисы для мониторинга транзаций и из синхронной репликации на несколько серверов. Tuxedo вроде как умеет это делать

Синхронная репликация это не проблема, расширение/failover кластера без остановки обслуживания клиентов вот это вот задачка...
Умеет Оракл это делать?

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

При использовании RAC виртуального IP и правильном конфигурировании параметров расчитанных на будущее расширение и хорошего админа не вижу проблем с добавлением новых узлов в кластер.

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

stuard писал(а):При использовании RAC виртуального IP и правильном конфигурировании параметров расчитанных на будущее расширение и хорошего админа не вижу проблем с добавлением новых узлов в кластер.

RAC!!!??
Гы, нам стока денег не дадут потратить, да и не скейлится он по достижению определенного предела, плавали, знаем

Shared storage sucks!

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

А вот интересно какие пределы интересуют. Я из своего опыта еще не встречал просто. Или хотят и задачу решить и денег не вкладывать. При разработке своего продукта не факт что в конечном итоге получиться дешевле. Ведь много других вопросов например поддержка

Marmot · Сообщение **Marmot** » 24 янв 2007, 21:54

stuard писал(а):А вот интересно какие пределы интересуют. Я из своего опыта еще не встречал просто.

У нас сейчас 50Кselects/sec +7K(updates/inserts/deletes)/sec
к концу года все это будет в 5-7 раз больше.

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

Ну продукт будет написан одним человеком месяца за 2-3

Это относительно недорого

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

ajkj3em · Сообщение **ajkj3em** » 24 янв 2007, 22:00

Marmot писал(а): Ну продукт будет написан одним человеком месяца за 2-3 :)

тред я не читал, о чем речь понятия не имею,
но могу с уверенностью сказать - месяцев там будет точно не 2-3

:)

Marmot · Сообщение **Marmot** » 24 янв 2007, 22:04

ajkj3em писал(а):тред я не читал, о чем речь понятия не имею,
но могу с уверенностью сказать - месяцев там будет точно не 2-3

Может и быстрее, это пока не ясно, зависит от того что мне еще в эти месяцы навесят

А деваться некуда, писать надо, а то плохо будет

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

Вот пример ORacle RAC два узла на AIX SAN storage. Объем 25ТБ изменений порядка 100000-500000 в минуту. Объем записи 300 байт. Используется для отчетности и как warehouse. данные закачиваются через batch джобы используя файлы, прямую загрузку и прочими примудростями. Файлы генерятся апликухой.

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

полностью согласен с ктулкху. если будет 2-3 месяца до развертывания на боевой машине - с меня конъяк

При таком количестве запросов там одного тестирования на месяц, все правда мое сугубое имхо

Marmot · Сообщение **Marmot** » 25 янв 2007, 09:38

stuard писал(а):Вот пример ORacle RAC два узла на AIX SAN storage. Объем 25ТБ изменений порядка 100000-500000 в минуту. Объем записи 300 байт. Используется для отчетности и как warehouse. данные закачиваются через batch джобы используя файлы, прямую загрузку и прочими примудростями. Файлы генерятся апликухой.

Гы, ты тоже что ли телефонист?
Ну это же совсем другой тип базы, и меня же OLTP.
Проблема с RAC-ом в том , что больше чем 8 машин в него ставить бессмысленно, они начинают тратить больше времени на выяснение отношений между собой чем на работу.
Как я уже сказал: shared storage sucks...
А у нас сейчас 50 машин shared nothing.
Можно конечно сделать отдельный RAC на каждый shard(partition), у нас их 18, но это будет полный .дец и в деньгах и в поддержке

Marmot · Сообщение **Marmot** » 25 янв 2007, 09:46

aissp писал(а): При таком количестве запросов там одного тестирования на месяц

Да они все распределены будут

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

Startup style development однако. Мы так уже много чего сделали со сравнимой сложностью в сравнимые сроки

Сами себе заказчики, дизайнеры, разработчики и поддержка

Обычно максимум 3 человека вовлечены, а чаще 1-2

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

Предложение остается в силе

делается за три месяца от старта до постановки на боевое дежурство (то есть непосредственно на боевые сервера в полном объеме) с меня либо ХО либо (что больше приветсвуется) глендфищ

(Alex) · Сообщение **(Alex)** » 25 янв 2007, 11:05

Одному быстрее писать, чем командой. Да и это всё таки java...

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

(Alex) писал(а):Одному быстрее писать, чем командой. Да и это всё таки java...

Да уж, в стандарты через строку заглядывать не надо

sz · Сообщение sz » 25 янв 2007, 11:19

Marmot писал(а):
(Alex) писал(а):Одному быстрее писать, чем командой. Да и это всё таки java...
Да уж, в стандарты через строку заглядывать не надо

Тогда пиши на brainfuck - там стандарт еще компактнее. Еще легче запомнить.