Комментарии 13
Зашёл в статью Вики
Это как????
Можете прокомментировать
Наиболее крупная база данных используется в АИС ФССП России, где суммарный объем центральной БД достигает 100ТБ, а максимальный размер одной физической БД доходит до 10 ТБ (собрать всю центральную БД воедино невозможно, так как СУБД не справляется с такими объемами). Здесь обрабатываются сотни одновременных подключений и сотни тысяч транзакций в час, документооборот превышает 1,2 млрд. документов в год с потерей данных не более 2% в год.
Здравствуйте!
Спасибо за внимательность и вопрос.
В статье википедии эти правки внесены анонимом без указания источников. Именно это комментировать не корректно. Но постараюсь ответить на Ваш вопрос.
На сегодняшний день суммарный объем ЦБД достигает 240ТБ. А отдельно взятой 15ТБ.
Предел для СУБД Ред База Данных 3.0 составляет 64ТБ. В версии СУБД Ред База Данных 5.0 этот предел значительно увеличен за счет табличных пространств. Об этом можно послушать тут.
Решение не использовать единую БД обуславливается не максимально допустимым пределом, а рядом других факторов: доступные носители (диски), архитектура системы, удобство администрирования, масштабируемость и кластеризация на уровне сервера приложений. Детали разглашать не буду. Извините.
Касательно показателей нагрузки, это наблюдается в подсистеме межведомственного взаимодействия, где нагрузка на службу одна из крупнейших в стране.
Я, конечно, не представитель компании РЕДСОФТ, но администрирую упомянутую систему. СУБД не справляется не то, что с парой ТБ, там и пары сотни ГБ хватает, чтобы обычный SELECT с парой JOIN отрабатывал от пол минуты до пары минут, периодически вызывая зависания всей подсистемы. Firebird слишком, слишком плохое решение для таких БД.
СУБД Ред База Данных отлично справляется с указанными нагрузками. Так, ее использует суперсервис «Цифровое исполнительное производство», который признан Минцифры самым быстрым онлайн сервисом на портале «Госуслуги».
https://d-russia.ru/red-soft-razrabotchik-samogo-bystrogo-servisa-na-portale-gosuslug.html
Возможно, у вас есть проблемы с "железом" или прикладным софтом. Обратитесь в ТП, мы вам поможем. Также у нас есть курсы обучения администрированию: https://reddatabase.ru/ru/services/
Мы будем рады помочь!
(del)
какой-то сон разума, на кой сторед процедура, где внутри по jdbc коннекция ? в чем смысл дребедень устанавливающую jdbc коннекцию упрятывать в субд ?
ну и по надежности - если это клон FB, то получается и лога транзакций нет. т.е. если произошел сбой восстановиться можно лишь на момент бэкапа. как в любой другой субд накатить лог транзакций уже не выйдет, верно понимаю ? случайно не отсюда ли уши у фразы "документов в год с потерей данных не более 2% в год" ?
На той, чтобы предоставить обычный доступ к интерфейсу JDBC внутри той-же или новой транзакции и позволить внешней подпрограмме получить доступ к содержимому БД с целью обработки данных.
По надежности вы понимаете неверно. СУБД Ред База Данных поддерживает все свойства ACID и всегда поддерживала. Лог транзакций не единственный способ обеспечения этих свойств. Применяется так называемый Careful Write, поддерживающий консистентное состояние БД на диске в любой момент времени. Посмотрите на канале Ютуб курс "Администрирование". Там об этом было. Или следите за каналом. Мы планируем подробнее об этом рассказать.
jdbc интерфейс полагаю еще борланд сделал. у db2, oracle тоже jvm внутри, но там есть смысл т.к. jvm часть ядра и работает с базой через внутренние протоколы.
да понятно, что если субд не имеет лога транзакций то вынуждена каждый коммит расскладывать по датафайлам. этот минус тоже от интербейз достался и не позволяет по перфоменсу сравнится даже с mysql. innodb пишет последовательно в лог, а в файлы данных расскладывает когда время найдется, не задерживая поток транзакций. плюс есть тьма сценариев когда может оказаться повреждены файлы данных. в любой, отличной от интербейз, базе данных можно взять ночной бэкап и накатить логи транзкции до момента сбоя. мягко говоря гораздо более разумный с точки зрения безопасности подход.
У нас jvm тоже запущена из ядра и тоже работает с базой напрямую из ядра. JDBC только интерфейс. А драйвер мы тоже контрибьютим и развиваем.
Про лог транзакции. То вы утверждали что все сбоит. Теперь понятно что нет, но оказывается медленно. Практика показывает что все хорошо при правильном подходе.
Был бы очень благодарен за тьму сценариев повреждения файлов. А в случае сбоя ничего не надо накатывать. Все целостно и так. Нулевое время восстановления. Ни одна СУБД так не умеет.
Откуда jvm запущена не столь важно, важно что jdbc сериализацией десериализацией вынужден заниматься, убивая смысл работы внутри субд.
По логу – сосредоточьтесь, никто показания не меняет, субд без лога не нужна и попахивает попилом, если юзается в гос учреждениях. Ведь на рынке доступны бесплатные и полноценные субд. Поврежденные файлы из того, что я сталкивался в последнее время – сходивший с ума контроллер, выходящие из строя вентиляторы и перегрев процессоров с удачными глючками. У соседей тестировали пожарную сигнализацию, сирены, звуком, умудрились убить сотни hdd. ситуаций полно и юзать субд без лога нет никакого резона.
Не могу придумать ни одного реального случая, где мне бы потребовалось писать триггеры / хранимки на языке отличном от pl/sql, pl/pgsql и им подобным. Хранимки в бд стоит воспринимать как интерфейс доступа к данным. И если у вас появляется потребность в бд делать что-то сложное, то с вашей архитектурой явно что-то не так. А уж если появляется потребность в java в бд, это прямо вообще что-то не так.
Ну и раз речь про java. Без обид, но примеры кода стоило сделать более enterprose-ready: декомпозиция методов, try-with-resources, типизированные данные, а то примеры выглядят как ответы со стековерфлоу из нулевых.
Хранимые процедуры, функции и триггеры на Java