ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Многофайловая база данных как способ ускорения доступа
24 сообщений из 24, страница 1 из 1
Многофайловая база данных как способ ускорения доступа
    #39766735
shalamyansky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
shalamyansky
Участник
Такая идея: разделить файл базы на несколько и разнести их на разные физические диски. Это в принципе возможно? А смысл в плане ускорения есть?

Текущая конфигурация:
Firebird 3.0 Superserver
Windows Server 2012
RAID5 2 Тб (3 SSD 1 Тб)
DB 0.5 - 0.7 Тб
...
Рейтинг: 0 / 0
29.01.2019, 18:51
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39766739
Vlad F
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vlad F
Участник
shalamyansky,

Невозможно. Потому и смысла нет.
...
Рейтинг: 0 / 0
29.01.2019, 18:56
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39766741
shalamyansky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
shalamyansky
Участник
Ну, на нет и смысла нет. А жаль.
...
Рейтинг: 0 / 0
29.01.2019, 19:02
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39766743
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
shalamyanskyЭто в принципе возможно? А смысл в плане ускорения есть?

Это возможно, но у тебя рейд-5, он уже читает куски параллельно и делает это гораздо
лучше, так что ускорения не будет.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
29.01.2019, 19:05
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39766754
Vlad F
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vlad F
Участник
shalamyanskyНу, на нет и смысла нет. А жаль.
Небольшая поправка, - невозможно в том смысле (партиционирования), что ты никак не сможешь управлять
реальным размещением конкретных составляющий в этих "автоматически создаваемых" частях. Ибо делалось
оно в старину для преодоления совсех других проблем. Потому и ожидаемого эффекта никакого не будет.
...
Рейтинг: 0 / 0
29.01.2019, 19:50
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39766757
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Vlad F,

то о чём ты говоришь это скорее относится к табличным пространствам (как раз таки разбиение БД на отдельные файлы).
А партиционирование (секционирование) немного другая вещь, оно может использовать разные табличные пространства, а могут и не использовать. Кстати секционирование индексов могло бы помогать уменьшать глубину индексов.
...
Рейтинг: 0 / 0
29.01.2019, 19:58
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39766848
mkr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mkr
Участник
а как на счёт того, чтобы вынести те же логи (историю изменений) и в отдельную базу
(требуются данные редко и пусть себе лежать отдельно)
...
Рейтинг: 0 / 0
30.01.2019, 09:08
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39766849
mkr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mkr
Участник
да и BLOB'ы
...
Рейтинг: 0 / 0
30.01.2019, 09:09
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39766850
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WildSery
Участник
mkr,

А как насчёт того, чтобы сделать для логов отдельную базу самому?
...
Рейтинг: 0 / 0
30.01.2019, 09:11
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39766855
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
mkr,

ты путаешь отдельную базу и другое табличное пространство той же базы данных.
Другую БД ты и сам можешь сделать.

З.Ы. В 4.0 EXECUTE STATEMENT ON EXTERNAL достаточно эффективен, ибо есть пул внешних соединений.
...
Рейтинг: 0 / 0
30.01.2019, 09:30
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39766856
Vlad F
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vlad F
Участник
mkr,

Я ж и говорю, - голосуй за тикеты на предмет введения табличных пространств, партиционирования и сегментирования.))
...
Рейтинг: 0 / 0
30.01.2019, 09:34
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39766892
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WildSery
Участник
Vlad F,

В основном это всё хрень, когда дисковые массивы были молодыми.
...
Рейтинг: 0 / 0
30.01.2019, 10:41
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39766913
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
shalamyanskyТакая идея: разделить файл базы на несколько и разнести их на разные физические диски. Это в принципе возможно? А смысл в плане ускорения есть?

Текущая конфигурация:
Firebird 3.0 Superserver
Windows Server 2012
RAID5 2 Тб (3 SSD 1 Тб)
DB 0.5 - 0.7 ТбЗачем городить огород и разносить базу на разные физические носители, если это уже делает RAID5? Не нравится RAID5 - поставьте RAID50 или даже RAID10, если в бюджете вашего АйТи много неосвоенных средств, но лучше купить какую-нибудь мощную СХД.
...
Рейтинг: 0 / 0
30.01.2019, 11:08
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39766922
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
WildSery, rdb_dev,

как минимум можно уменьшить объём физических бекапов.

WildSery,

партиционированию RAID никак не поможет, а выигрыш на нём можно получить значительный, если конечно оптимизатор будет специальные методы доступа применять
...
Рейтинг: 0 / 0
30.01.2019, 11:29
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39766981
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
Что сказал перфмон на предмет очереди к диску?

Сколько коннектов? сколько ОЗУ? Какой рэйд адаптор?

Глупо что-то такое оптимизировать на довольно объемной базе без данных мониторинга.

Сдается мне рэйд5 не самое лучшее решение для БД, если нагрузка на запись достаточно интенсивная.
У себя ставим либо Raid10+HS либо Raid1+HS
...
Рейтинг: 0 / 0
30.01.2019, 12:50
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39766982
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
rdb_devлучше купить какую-нибудь мощную СХДЭто такая штуковина, с которой надо УМЕТЬ работать и ценник может неподготовленного "эффективного манагера" может доконать с лету. :)
...
Рейтинг: 0 / 0
30.01.2019, 12:52
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39767001
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Симонов ДенисWildSery, rdb_dev,
как минимум можно уменьшить объём физических бекапов.С этим прекрасно справляется ZFS, причем, даже не надо делать резервные копии в привычном понимании FirebirdSQL, а достаточно лишь хранить каждую базу на отдельном логическом томе ZFS и периодически делать мгновенные снапшоты тома. Тут тебе и бэкапы и уменьшение их объема в одном флаконе.

Симонов ДенисWildSery,

партиционированию RAID никак не поможет, а выигрыш на нём можно получить значительный, если конечно оптимизатор будет специальные методы доступа применятьА смысл? В iSCSI есть "tagged queue", который появился в SCSI еще в 90 лохматых годах, под который есть смысл оптимизировать работу кэша, если у тебя только один физический носитель, но так как сейчас по iSCSI работают СХД в которых встроенный рейд сам оптимизирует чтение с кучи накопителей на более низком уровне, нафига нужна эта оптимизация на стороне менеджера кеша?
...
Рейтинг: 0 / 0
30.01.2019, 13:27
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39767007
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
rdb_dev,

причём тут куча накопителей? Ты не понимаешь о чём речь.

Партиционирование (секционирование) может помочь в ряде случаев ограничить FULL SCAN таблицы или индекса, а также уменьшить глубину индекса за счёт того что он разбит. И это к множеству накопителей вообще отношение не имеет, секции могут быть созданы как в одном табличном пространстве так и в разных.
...
Рейтинг: 0 / 0
30.01.2019, 13:38
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39767040
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
rdb_devС этим прекрасно справляется ZFSНасколько хорошо оно работает в паре с файрбердом? Ты сам пробовал? как оно относительно ext4 на том же железе?
...
Рейтинг: 0 / 0
30.01.2019, 14:33
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39767201
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WildSery
Участник
Симонов ДенисПартиционирование (секционирование) может помочь в ряде случаев ограничить FULL SCAN таблицы или индекса, а также уменьшить глубину индекса за счёт того что он разбит.Вот эту фразу не понял.
Звучит как "если половину данных в таблице сделать недоступными, то вторая половина читаться будет в 2 раза быстрее".
...
Рейтинг: 0 / 0
30.01.2019, 16:53
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39767210
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
WildSery,

нет просто можно один индекс разбить на несколько поменьше (подиндексов) по диапазонам значений например, и оптимизатором определять какую часть читать. Тоже самое с самой таблицей при фулсканах без индексов. Обычно такое делается для больших таблиц в которых например есть дата, их секционируют например по годам. В 90% случаев читается только малое количество данных за рабочий период.
...
Рейтинг: 0 / 0
30.01.2019, 17:00
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39767212
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WildSery
Участник
Симонов Денис,

А что, просто индексы, без партицирования, как-то сильно по-другому работают? Или индекс всегда целиком, независимо от объёма, читается?
...
Рейтинг: 0 / 0
30.01.2019, 17:05
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39767235
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
WildSery,

почти тоже самое, разве что глубина индекса меньше будет. Там ещё по идее и уменьшение затрат на перестройку индекса должно быть, когда страницы расщепляются.
В общем в других СУБД где это есть выгода ощущается причём не важно как оно разбросано по табличным пространствам, как оно должно быть в ФБ не знаю. Это лучше Дима или Влад скажут.
...
Рейтинг: 0 / 0
30.01.2019, 17:19
| Ответить | Цитировать | Написать  
Многофайловая база данных как способ ускорения доступа
    #39767573
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Ivan_Pisarevskyrdb_devС этим прекрасно справляется ZFSНасколько хорошо оно работает в паре с файрбердом? Ты сам пробовал? как оно относительно ext4 на том же железе?Не знаю, не тестировал, поскольку ZFS у меня дома на сетевом хранилище, которое крутится на "мамке" GA-J1900N-D3V с чипсетом "Intel Bay-trail" и RAID контроллер PCI-X 3Ware 9500S-4 в RAID5 на четыре двухгиговых диска воткнут, соответственно, в PCI и потому работает вполсилы. В общем, далеко не серверная платформа, пропускная способность PCI шины и пропускная способность домашней гигабитной сети не позволят, в моём случае, адекватно оценить производительность доступа к базе FirebirdSQL сервера по iSCSI.

Сейчас даже не помню какой именно алгоритм выбирал для хэш-индексов страниц - MD5 или SHA-256... Скорее всего делал SHA-256 + сравнение контента страниц при совпадении хэша. Соответственно, при многочисленных операциях записи на ZFS для вычисления SHA-256 нужно иметь либо адекватную процессорную мощность, либо какой-нибудь вспомогательный крипто-контроллер, который умеет пользоваться линуховое ядро.
...
Рейтинг: 0 / 0
31.01.2019, 13:24
| Ответить | Цитировать | Написать  
24 сообщений из 24, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Многофайловая база данных как способ ускорения доступа
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=39767210&tid=1560824]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 155ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 56ms
get tp. blocked users:
 1ms
others: 349ms
total:  604ms
созд. / загр.: 604ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]