Лыжи не едут...,

ты про упоминание FAT32/ext2 ?

Многофайловые базы данных являются результатом старых файловых систем, где абсолютный предел размера файла 2 Гбайта (FAT32, ext2) или 4 Гбайта (система NTFS с 32-битовым вводом/выводом)

Мимопроходящийтак это ж Бондарь
вот не надо грязи.

Цитирую оригинал:

Multi-file databases are more of an issue on older filesystems where the absolute limit for a shared-write file is 2GB (FAT32, ext2) or 4GB (NTFS systems with 32-bit I/O).

перевод полностью соответствует исходному тексту.

Если Хелен и ошиблась, указав, что макс. размер файла на FAT32 это 2 гига, то не сильно. Он 4 гига. А раньше на винде, на FAT32, файл больше 2 гиг было просто невозможно скопировать на другой логический диск.

В ext, согласно википедии, размер файла именно не больше 2 гиг. В ext2 - насколько я понял, макс. размер файла зависит от размера кластера

так что в тексте ошибок две.
1. 4 а не 2 гиг для FAT32
2. ext2 вместо ext

Лыжи не едут...,

ну и вам, как автору топика - не заставляйте гадать, не надо намеков. Пишите явно, что вы считаете "косяком".
Например - "вот там написано вот так, а на самом деле оно вот эдак. Я прав?".

Гаджимурадов РустамДело в том, что кому вообще нафиг нужны эти многофайловые БД сегодня.
you are absolutely right!
поэтому в русском LR есть пометка о том, что это атавизм. К сожалению, синтаксис позволяет, поэтому описывать нужно.
Хотя я бы урезал так, что как будто-бы никаких "многофайловых БД" больше нет.

arniТеоретически можно разнести на разные носители и поднять i/o (правда ценой снижения надежности системы).
Однако не знаю насколько практические опыты подтверждают это предположение насчет перфоманса.
тут и без тестов я тебе могу сказать, что эффект будет только если
1. использовать одиночные HDD
2. каждый отдельный файл БД класть на отдельный HDD. Например, 1 файл в 10 гиг на одном диске, второй - на другом, и т.д.
3. используется архитектура Classic/SuperClassic (в 2.5)
4. разные коннекты попадают на чтение/модификацию данных, которые находятся в разных файлах.

В общем и целом это все бесполезный выхлоп, плюс явный геморрой при администрировании. Куда лучше сделать raid 10 из четырех таких одиночных HDD, и на них положить однофайловую БД.

Гаджимурадов РустамНаверное, это логично. Но не факт, что активная часть будет та, что нужна, кроме кэша есть и другие варианты.
Обычный raid 10 по сравнению с "многофайловыми БД" даст преимущества уже только потому, что данные на нем равномерно размазаны.
Даже если ты разберешь этот raid 10 на 4 части (ну или пусть на две по raid1), tablespace на этих двух (или четырех) частях были бы медленее, чем raid 10.

Рэйды, про которые сказал Иван, имеют, например, схемы из нескольких блоков накопителей, например, SSD и HDD, где контроллер сам перемещает данные между HDD и SSD.
Конечно, если пол-месяца идут обращения к одной половине БД, а вторые - к другой, неизвестно как поведет себя такой контроллер. Но тогда проще всю БД положить целиком на raid из SSD. Да, можно было бы еще ускорить, если иметь tablespace и разложить их на 2 рэйда из SSD :-)
Правда, я в tablespace вижу несколько иные выгоды, чем просто ускорение.

Dimitry SibiryakovКакие?
например, частичный бэкап.