распределенная БД

← →
ev © (2002-06-01 20:17) [0]

Сегодня (на встрече мастеров) мне сказали, что сабж с IB сделать невозможно! Отсюда вопросы:
1. это действительно так (если Да, то как выйти из положения)?
2. как грамотно делать резервирование БД IB на другом компьютере?

← →
Alexandr © (2002-06-03 06:59) [1]

1) все можно, только кода больше писать надо.
2) backup ?

← →
ev © (2002-06-03 08:25) [2]

2 Alexandr © (03.06.02 06:59)

1. что Вы имеете ввиду? Мне надо, чтобы одна БД была на несколькик компьютерах. Как это можно реализовать (или где почитать).

2. т.е. я добавляю запись в таблицу, а она АВТОМАТИЧЕСКИ (средствами interbase) появляется и на другом компьютере (который выполняет роль резервной БД).

← →
Alexandr © (2002-06-03 09:26) [3]

1. Ты скажи сначала нафига. Тебе такое? Ты знаешь, что IB это клиент-серверная БД, и считается нормальным иметь одну базу в сети и много клиентов, работающих с ней.
2. Вообще-то есть IBReplicator, с помощью которого такое можно проделать, но проще самому написать. А нафига тебе резервная база данных ( просто архив базы данных (снимок) не подойдет?)

ты уж определись конкретно, что тебе надо, тогда уж посмотрим, как это сделать.

А так, какие-то праздные рассуждения типа круто/не круто...

← →
Praco © (2002-06-03 09:47) [4]

Alexandr ©
Распределенная БД нужна часто. Классический пример - общий склад и несколько удаленных магазинов.

ev © (01.06.02 20:17)
Отсутствие штатных средств репликации - большой минус IB. Но сабж это не только синхронизация. Это еще и поддержка распределенных транзакций. Так что реализовать сабж можно, но лучше подумать о MS SQL, Sybase и выше, ИМХО.

Мне рассказывал один дядька о крупной американской фирме, производящей ПО для торговых предприятий, они используют исключительно средства Borland. И реализовали множество систем с распределенными базами на IB.

← →
Yuri K. (2002-06-03 10:11) [5]

Насколько я понимаю, речь идет не о распределенной БД, а о репликации. У IB я репликацию не настраивал, но вроде там по описанию такая возможность есть.

← →
Шамиль (2002-06-03 10:55) [6]

Я несколько не въехал - если есть сетка, то зачем распределенные базы? А если сетки нет и синхронизация через дискеты и т.п. - какая ж тут автоматика? Всяко придется процедурку записи на дискету писать.

← →
Alexandr © (2002-06-03 12:05) [7]

Нет Если общий склад и несколько магазинов, то в первую очередь стоит подумать о трехзвенке, а не репликации

Как это нет штатных средств? А IBReplicator в конце концов?

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

А репликацию не настраивают, ее делать надо.

← →
ev © (2002-06-03 13:46) [8]

1. Распределить нагрузку по разным компьютерам (слишкомм много клиентов).

2. А резервная база данных нужна, если выйдет из строя основная. Т.е. 100% резервирование.

← →
Alexandr © (2002-06-03 13:56) [9]

1) Поставь Firebird Classic Server на Unix (Linux)
2) Поставь Yaffil Classic Server на Windows
Эти две конфигурации поддерживают многопроцессорность.
Особенно если памяти побольше...
Это решит проблемы с нагрузкой :) Хотя все относительно.
Вот тебе и нагрузка.

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

ДА не падает просто так Interbase он может годами без перезагрузки работать, а если еще и backUp делать почаше, то 100% резервирование может и не нужно?

← →
Alexandr © (2002-06-03 13:57) [10]

а вообще-то это смахивает на универсальный решатель задач с речевым вводом

← →
ev © (2002-06-03 14:31) [11]

2 Alexandr © (03.06.02 13:56)
А если сеть не позволяет большую нагрузку?

> ДА не падает просто так Interbase он может годами без
> перезагрузки работать
Это факт, или ИМХО?

← →
Alexandr © (2002-06-03 14:55) [12]

если сеть не позволяет большую нагрузку, тогда легкая трехзвенка.

А насчет стабильности работы это факт, если у админа и разработчика руки не кривые.
У меня несколько месяцев без перезагрузки сервер win2000 Serv + IB5.6 работает. (потом приходится, но не из-за Interbase, а из-за Windows, установки нового ПО, глюков других программ и пр.)

← →
ev © (2002-06-03 17:29) [13]

2 Alexandr © (03.06.02 14:55)
Что ты подразумеваешь " легкая трехзвенка".

← →
shiva1 © (2002-06-03 18:14) [14]

У меня IB более года на сервере без перезагрузки, и никаких глюков.

← →
Alexandr © (2002-06-04 06:46) [15]

вообщем, просто трехзвенка. Которая траффик по сети зазря не гоняет.

← →
Sergey13 © (2002-06-04 09:25) [16]

2ev © (03.06.02 13:46)
>слишкомм много клиентов.
Это сколько?
2ev © (03.06.02 14:31)
>А если сеть не позволяет большую нагрузку?
А что за сеть такая и что за нагрузка?

2ev ©
А для начала, я бы посоветовал не западать на трехзвенки-распределенки, а просто проверить приложения на наличие запросов типа
Select * from Table
без условий. И поковырять планы запросов. И проверить частоту обновлений результатов запросов. И т.д. и т.п.
Где то я читал "адын умный вещь", что любая аппаратно-софтовая(имеется в виду что то типа смены драйверов, версий и т.п.) настройка производительности дает прирост, как правило, максимум 20~30%. Настройка и отладка приложения (в основном SQL-запросов и логики их применения) может повысить производительность в РАЗЫ. И в том и в другом сам убеждался не единожды. К тому же второй путь проще и интереснее с чисто программитской точки зрения.

В общем "Пилите, Шура, пилите. Они золотые."

← →
ev © (2002-06-04 09:50) [17]

2 Alexandr © (04.06.02 06:46)
Т.е. серверов БД делать несколько, а сервер приложений - один.
А что будет, если сервер приложений не выдержит нагрузки.

p.s. предпологается одновременно более 10000 соеденений.

← →
ev © (2002-06-04 09:55) [18]

От отдного пользователя поступает 1.5 млн записей в сутки (insert 50-100 байт ). А пользователей на один сервер я хочу минимум 1000.
Плюс множество пользавателей делают выборки (иногда и по 1-2 млн записей).
Или это не реально.

← →
Praco © (2002-06-04 10:15) [19]

"предпологается одновременно более 10000 соеденений.
От отдного пользователя поступает 1.5 млн записей в сутки
пользователей на один сервер я хочу минимум 1000. "

1500000 * 1000 = 1 500 000 000 записей в сутки
"Плюс множество пользавателей делают выборки (иногда и по 1-2 млн записей)."

Что это? Американская национальная телефонная компания заказ дала? :)
IB не потянет. Oracle может и потянет на соответствующем железе.

← →
Sergey13 © (2002-06-04 10:15) [20]

2ev © (04.06.02 09:55)
Если не секрет, что за задача такая?
Если все это действительно нужно, то вам прямой путь на Oracle ЕЕ(или что то похожее)+ оптоволокно+многозвенка+распределенка+черт знает что. + Это будет стоить уйму зеленых американских президентов на бумажном носителе.
А вы хотели все это сделать на фришном IB? Ха-Ха-Ха. Такие проекты стоят миллионы, и не рублей.

← →
Anatoly Podgoretsky © (2002-06-04 11:16) [21]

ev © (04.06.02 09:55)
Да это же более 5000 Терабайт в год, тогда насчет нескольких миллионов зеленых тебя обманули, речь идет или л десятка или о сотнях мегабакс и особо производительные каналы

← →
Alexandr © (2002-06-04 11:26) [22]

:)

жалко тут юмор не собирается...

Пора ветку перенести в "потрепаться"

← →
ev © (2002-06-04 11:49) [23]

Можно посчитать:
(1.5 млн записей в сутки) * (50 байт ) = 75 Мегабайт
(75 Мегабайт от одного пользователя) * 1000 = 75 Гигабайт
Это в сутки. Если учитывать, что максимума не будет, то винт на 80 ГБ (что сейчас не редкость) будет уходить на 1-2 дня.

Информация хранится долго не будет! Устаревшая информация будет уничтожаться или сбрасываться в архив. Это надо просто для статистики.

Вопросы в слудующем:
1. потянет ли Interbase (если нет, то сколько потянет)
2. насколько по надежности хватит винтов

p.s. Сейчас у меня проект - винт 80 ГБ забивается за 5-6 дней, потом немного удаляется, опять забивается.... и так по циклу.
IBM вылетает за пару месяцев. Сейчас взял Баракуду4 - посмотрим...

← →
Alexandr © (2002-06-04 11:52) [24]

а ты уверен, что тебе для первичную информацию надо в базе держать?
Может ее обрабатывать отдельно, а в базу только результирующую информацию заносить?

По-моему так правильнее...

← →
ev © (2002-06-04 13:25) [25]

Статистическая информация актуальна несколько дней, потом стирается. Но если была бы возможность (винты по млн. ТераБайт), то я не стирал даже устаревшую на месяц, а то и на год.

То, что я писал от (04.06.02 11:49) - практический маскимум. Т.к. для разработки этот максимум надо учитывать. А так я надеюсь, что объем будет в 3-5 раз меньше.

← →
Delirium © (2002-06-04 18:03) [26]

Эта та самая ситуация когда MSSQL однозначно сильнее IB :)

← →
ev © (2002-06-04 19:48) [27]

А если мне надо unix (надежней, чем MS)?
Oracle - дорого.
Структурную схемку реализации репликации и резервирования (используя IB) я уже нарисовал.
Но остается 2 вопроса:
1. потянет ли Interbase такой поток данных (если нет, то сколько потянет)
2. насколько по надежности хватит винтов

Ну не потянет 1000 пользователей, можно и два компьютера поставить - это допустимо.

← →
Delirium © (2002-06-04 19:54) [28]

Я бы предложил систему ветвления (с MSSQL так можно):
ставятся промежуточные сервера - один на 50 клиентов (например), это сервера-подписчики у них один сервер-дистрибьютор. Далее все дистрибьюторы являются подписчиками следующего уровня (можно опять по 50 объединить), для них свой дистрибьютор и так до бесконечности.

Надо только уровни репликации грамотно распределить, дабы каналы не перегружались.

Упростим задачу (не так часто статистику собитать).
(50 байт) * (15000 запросов) = 750 КБайт
(750 КБайт) * (1000 пользователей) = 750 МБайт

Это статистика за сутки (для 1000 пользователей).
Ну такое-то потянет сервер?

Мне для отчета надо выяснить максисальную "пропускную способность" сервера. Исходя из этих значений будет уже строится ТЗ.

p.s. как бы ни хотелось 1.5 млн запросов - это не реально.

Хм, проблема на мой взгяд не в сервере, а в связи - наращивать базу на 1 гигобайт каждый день это не проблема, можно и на 10 наращивать - как прокачать этот гигобайт? Или речь идёт о локалке ?

локалка

в связи с игнорированием моих последних постов в эту ветку, а прекращаю писать в нее.

2 Alexandr © (05.06.02 07:04)
Почему игнорирование? Я же написал, что это статистическая информация.
А статистика не может обрабатываться сразу. Или я не прав?

ладно.

Прав - не прав.
Откуда я знаю, я же ТЗ не видел.
Тебе транзакции и прочие прелести Interbase нужны?
Или может MYSQL или даже dbf можно в этом месте обойтись?
А в Interbase хранить уже обработанные данные.
Ну не знаю я твоего ТЗ: я просто варианты предлагаю.
И помни, что бызвыходных ситуаций не бывает. Все можно сделать.

Ненормально это: Большим потоком в реальном времени вгонять данные в SQL сервер. Что-тут не так в проектировании.

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

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

А вообще-то сдается мне, что ты биллинг делаешь для телефонной станции. Угадал?

ev © (04.06.02 19:48)
Начинать надо с постановки техзадания, может и окажется, что Оракл в этом случае просто задаром, или даже просто не потянет.
Одно надо сразу учесть, зависимость физических размеров базы от операционной системы.

> Тебе транзакции и прочие прелести Interbase нужны?
Да.

> А вообще-то сдается мне, что ты биллинг делаешь для телефонной
> станции. Угадал?
Нет. Это просто статистическая информация о работе некоторых компьютеров в сети (не троян!).

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

Все делло в том, что размерность добавляемых данных от 50 до 100 байт. Но количество запросов на добавление данных (от одного клиента) может быть очень много.

Вот, что планирую: на 1000 пользователей приходится 3 сервера:
- на первый происходит запись
- на второй происходит периодическая репликация с первого сервера (нужен для разгрузки первого сервера, с него происходит только чтение)
- третий служит для резерва

И собственно встают вопросы:
1. что реально можно реализовать, что прописать в ТЗ (будут мифические числа, а потом мучайся).
2. Как лучше производить периодическую репликацию с первого сервера на второй?

2 модератору

странные у тебя понятия о соответствии веткам и темам форумов :(

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

Практика тебе нужна. Так-что пробуй...

распределенная БД Найти похожие ветки