Перейти к содержанию
    

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

Здравствуйте.

Необходимо писать данные, которые поступают по 100 байт каждую 1мс , в файлы на жестком диске.

Вопрос, как будет быстрее и производительнее:

1. Пишем все в таблицы MySQL и один раз в день все из БД сохраняем в файлы;

2. Пишем напрямую в файлы потоками?

Спасибо.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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 раз в секунду Винда скидывать свои буфера на диск не будет, даже если вручную потребуете, но хрустеть винтом будет часто.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

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

Судя по тому что вы написали вам нужна скорость записи 100кб/с.

Современные винчестеры могут гораздо больше.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

DASM, ms1, andrewlekar, спасибо большое!

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Прям так безапелляционно? :biggrin:

Не глядя ни какая файловая система,

ни какая дефрагментация у диска,

ни как загружена система другими файловыми операциями ,

ни какой приоритет у процесса пользователя,

ни какие перехватчики на файловых операциях,

ни как осуществляется контроль доступа к файлу,...

 

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

 

DASM, ms1, andrewlekar, спасибо большое!

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

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

 

А что, кто-то привел цифры, убедительные аргументы?

SQL сервера специально затачиваются под быстродействие операций не только выборки, но и сохранения.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Проводить сравнения надо.

Файловые операции тоже используют индекс.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Сразу захочется чего то побыстрей да поавтоматизированней.

 

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

 

Что, парсили контейнеры mkv и проч.?

Там один встроенный XML уже требует движка базы данных.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Вот и ворочайте такими файлами как семечками с помощью файловой системы.

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

Изменено пользователем menzoda

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...