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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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