Что быстрее и производительнее, запись в MySQL или в файлы? Опции

[Alt.F4]

Здравствуйте.
Необходимо писать данные, которые поступают по 100 байт каждую 1мс , в файлы на жестком диске.
Вопрос, как будет быстрее и производительнее:
1. Пишем все в таблицы MySQL и один раз в день все из БД сохраняем в файлы;
2. Пишем напрямую в файлы потоками?
Спасибо.
P.S. Я задался этим вопросом, т.к. MySQL хранит свои таблицы в оперативной памяти, которая намного быстрее жесткого диска.

[DASM]

MySQL сама по себе нужна или прельщает именно хранение в ОЗУ ? Если последнее - то воспользуйтесь проекцией файла в память. И быстро будет, и подгружать будет только нужные виртуальные страницы в память процесса, и скинуть в физический файл просто. МСДНьте по слову CreateFileMapping(); или отсюда начните http://ru.wikipedia.org/wiki/%D0%9E%D1%82%...%8F%D1%82%D1%8C
В Линуксе это вроде http://pubs.opengroup.org/onlinepubs/96999...s/shm_open.html shm_open будет, но я не пользовал, только mmap часто был нужен.
PS напрямую даже если будете писать - все равно 1000 раз в секунду Винда скидывать свои буфера на диск не будет, даже если вручную потребуете, но хрустеть винтом будет часто.

[ms1]

P.S. Я задался этим вопросом, т.к. MySQL хранит свои таблицы в оперативной памяти, которая намного быстрее жесткого диска.

OS тоже не пишет прямо на диск кстати, если об этом прямо не просить.
Данные сначала помещаются в буфер, а затем уже более крупными кусками сбрасываются на диск.
Судя по тому что вы написали вам нужна скорость записи 100кб/с.
Современные винчестеры могут гораздо больше.
Однако в любом случае (MySQL, memory mapping, прямая запись на диск или даже прямая запись в предварительно выделенный буфер в ОЗУ) не следует ожидать, что OS будет готова принять ваши данные каждые 1 мс.

[DASM]

OS тоже не пишет прямо на диск кстати, если об этом прямо не просить.

Даже если просить. И вообще, тут вопрос откуда эти данные берутся. Потому как что СОМ порты, что ЮСБ и сетевые стеки имеют свои буфера, что значительно упрощает положение вещей, избавляя от "100 байт 1000 раз в секунду"

[andrewlekar]

Быстрее писать в файлы. Если потом будете по этим данным что-то искать, то mysql будет делать выборку значительно быстрее, чем вы сможете это сделать руками.

[Alt.F4]

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

[AlexandrY]

Быстрее писать в файлы. Если потом будете по этим данным что-то искать, то mysql будет делать выборку значительно быстрее, чем вы сможете это сделать руками.

Прям так безапелляционно?
Не глядя ни какая файловая система,
ни какая дефрагментация у диска,
ни как загружена система другими файловыми операциями ,
ни какой приоритет у процесса пользователя,
ни какие перехватчики на файловых операциях,
ни как осуществляется контроль доступа к файлу,...

А если еще раз подумать?

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

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

[andrewlekar]

А если еще раз подумать?

А если ещё раз подумать, то ни на какой вопрос вообще нельзя 100% объективно ответить. Из общих соображений, SQL сервера заточены под работу с кортежами данных, как правило для быстрой выборки по индексу с не очень быстрой вставкой. Если в mysql писать с частотой в 1000 Гц неструктурированные данные, производительность будет трещать по швам.

[AlexandrY]

А если ещё раз подумать, то ни на какой вопрос вообще нельзя 100% объективно ответить. Из общих соображений, SQL сервера заточены под работу с кортежами данных, как правило для быстрой выборки по индексу с не очень быстрой вставкой. Если в mysql писать с частотой в 1000 Гц неструктурированные данные, производительность будет трещать по швам.

Проводить сравнения надо.
Файловые операции тоже используют индекс.
Какие вообще большие структуры могут не использовать индекс для поиска?

[andrewlekar]

Какие вообще большие структуры могут не использовать индекс для поиска?

Видео, картинки, музыка.

[menzoda]

О чем вообще речь? 100 байт раз в миллисекунду - это 100Кб/с, то есть вообще не ощутимо для любого (особенно современного) ПК, а если буферизировать запись и писать один раз в секунду или реже, то вообще как слону дробина. Делать что ли нечего, занялись преждеверменной оптимизацией? Ну давайте, можете взять базу данных, лучше быструю NoSQL какую-нибудь, оперативки докупить 32 Гб, четыре SSD диска в RAID0 поставить, коли заняться нечем.

[AlexandrY]

О чем вообще речь? 100 байт раз в миллисекунду - это 100Кб/с, то есть вообще не ощутимо для любого (особенно современного) ПК, а если буферизировать запись и писать один раз в секунду или реже, то вообще как слону дробина. Делать что ли нечего, занялись преждеверменной оптимизацией? Ну давайте, можете взять базу данных, лучше быструю NoSQL какую-нибудь, оперативки докупить 32 Гб, четыре SSD диска в RAID0 поставить, коли заняться нечем.

Ну да 8 Гиг в сутки. Вот и ворочайте такими файлами как семечками с помощью файловой системы.
Сразу захочется чего то побыстрей да поавтоматизированней.

Видео, картинки, музыка.

Что, парсили контейнеры mkv и проч.?
Там один встроенный XML уже требует движка базы данных.

[andrewlekar]

XML требует движка БД? Вы уже чё-то выдумываете. Давайте уже не будем оффтопик разводить.

[AlexandrY]

XML требует движка БД? Вы уже чё-то выдумываете. Давайте уже не будем оффтопик разводить.

Просто хочу указать что умозрительные представления о музыке и фалах не дают никакой информации о быстродействии.
Контейнер мультимейдийного файла может содержать структуры данных с неколькими индексами и чем же вы их будете обрабатывать как не методами баз данных?

[menzoda]

Какая разница сколько получается в сутки? Вопрос был про производительность при записи, ворочать ничем не надо, зачем придумывать задачи, которые ТС не требовал. Да пусть бы и двадцать гагабайт, заполнили один файл - создаем другой.

Вот и ворочайте такими файлами как семечками с помощью файловой системы.
А база данных прям будет квантами во всемирном эфире манипулировать. Она точно так же будет использовать файловую систему и создавать точно такие же гигабайтные файлы (SQLite), или, что хуже, десятки файлов поменьше (MySQL к примеру). База данных хороша, если надо обрабатывать сотни гигабайт сложносвязанных данных, а не вести лог 100Кб/с.

Сообщение отредактировал menzoda - Jul 15 2014, 07:15