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

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

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

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

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

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

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



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

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

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

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

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

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



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

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

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

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

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

В форуме почти каждый ответ это вопрос.
Т.е. вы хотели спросить зачем эти файлы нужны потом? Но стеснетесь это спросить у TC.

Но я уверен что для чего бы они потом не использовались их нужно будет прореживать или как-то обрабатывать.
Я бы в любом случае протестировал SQL сервер.

Надо дальше копать условия. сравнивать.
В памяти хранить данные - хранят. но это не значит что на момент вставки не будет произведена операция обеспечивающая целостность
данных - т.е. сброс в кэш (обычно) и далее в таблицы. и то и то - винт обычно. Выборка по условия скорее всего будет лучше,
если требуется некий анализ либо гибкое связывание табличных данных. (пример: в своё время участвовал в разработки своей ОО БД.
задействован был в частности в создании низкоуровневого движка. По скорости шустрее беркли вышло, под форточками.
Но то и понятно. У берлки - там ышо транзакционный слой, языковая поддержка, и т.д. и т.п.. Т.е. фокусов нет, если скорость то
обычно за счёт чего то.)

таблицы используют файловую систему. исключение составляет специальные аппаратные БД. Типа AS400 от IBM. Там нет в принципе
понятие файловой системы. Соответственно и выигрыш по скорости получается.

Надо так-же понимать, что работа самой БД определяется многими параметрами. Политикой изоляции, транзакционности и прочая лабуда.
Т.е. вполне возможно сегодня БД будет шустро, а завтра повернув выключатель в настройках Вы можелете получить другую картину.
Всё зависит уже от конкретики. Отсюда и надо плясать собственно. Если Вам универсальность, отказоустойчивость,
многопользовательский доступ, миграция в будущем, стандартные административные заморочки - то напрашивается БД.

Если есть механизм конкретной заточки под конкретное железо (кстати и форточки можно до ума доводить - но то уже лучше
копнуть любителей писать игры реал-тайм под форточками = многое чаво интересного можно подчерпнуть, кстати) и Вы сами с усами
на любом уровне абстракции в конкретной оси - то лучше сделать шустро

MySQL конечно же лёгкая БД. Но всё же это БД.

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

В смысле слили проблему другим?
Тоже выход.

Скорее закрутил единственный шуруп отверткой, не доставая из дальнего угла гаража шуруповерт, что есть правильно. Недавно видел подобное обсуждение, на реддите вроде, так вот там правильно сказали, что если единственный имеющийся инструмент - это молоток, то все вокруг будет выглядеть гвоздем. Я про то, что если в какой-то области реляционная база данных это круто и удобно, то не надо пихать ее во всё.

Единственное, хочу обратить внимание на параметр IOPS вашего накопителя. Не стоит писать много мелких файлов в одну директорию - со временем, это деградирует файловую систему.
Старайтесь избегать файлов размером 0,5-128 Кб - даже если будете писать такие файлы на RAMдиск (Справедливо для NTFS) больше 3000 файлов в секунду не получите, как бы не старались. сохраняйте данные только большими фрагментами, это позволить задействовать параметр линейная скорость записи у накопителя - а он всегда быстрее в разы.

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

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

в конечном итоге зависит от реализации оси и ФС. Если брать бытовой виндоус, то есть флаги при открытии файла - именно они
могут ограничить режимы открытия одного и того-же файла разными процессами. Далее только способ общения и способ
синхронизации буферов (на уровне ФС, оси, драйверов)... Обычно ФС сразу предствляют лёгкий закос на объекты синхронизации -
блокировки участка файла. Обычно это использовалось до клиент-серверные времена. Или точнее сказать во времена многопользовательского
доступа с помощью файовых систем. Яркий представитель этого хозяйства - клиппер, dbf формат, способ блокировок и доступа к БД файлам.

Сегодня провел опыты на VPS Windows Server 2003.
Результаты удручающие, прямая запись на жесткий диск сильно замедлила систему, загрузка ЦП 100%.
Вернул запись в MySQL, все летает...
з.ы. возможно все дело в соседях, но БД тоже ведь юзает HDD.

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

Чудес то не бывает. Он пользуется теми же сервисами записи на диск.
Поэтому быстрее никак быть не может


Ничего плохого. Зависит от ОС, будет ли он видеть новые данные или нет.

смешной вопрос - смешные ответы

x893 , будьте так добры - загляните в личку.

Разрешил вопрос с хостером VPS, в момент предыдущего тестирования они делали перенос виртуальных серверов, что нагрузило HDD и мои выводы оказались преждевременными.
Размеры таблиц в MySQL значительно уменьшились после переноса редко используемой инфы в файлы, что в результате ускорило работу самого движка БД (сужу по загрузке ЦП процессом MySQL).
В одном месте прочитал, что лучше сохранять файлы небольших размеров, однако в итоге экспериментов пришел к выводу, что чтение гораздо быстрее происходит при загрузке одного большого файла, чем множества маленьких.
Спасибо большое всем за помощь!!!