Что лучше / быстрее? MySql или FileSystem?

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

Я признаю, что мои SQL- запросы могли бы быть лучше, но в целом, что было бы быстрее и потребляло бы меньше вычислительной мощности.

Чтобы проверить, существует ли файл, а затем откройте его или

проверьте MySql, чтобы увидеть, если био существует и отобразить его.

Я уверен, что в приведенном выше случае файловая система будет курить базу данных MySQL.

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

Что быстрее в этом случае?

Есть ли определенный момент, когда, если в текстовом файле слишком много записей, лучше использовать MySql?

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

Итак, файловая система может работать для вас в некоторых случаях, но, конечно, не во всех.

Это действительно зависит от того, что вы делаете. В общем, скорость, с которой вы можете открыть файл для чтения, будет лучше, чем скорость, с которой вы можете установить сетевое соединение. Поэтому для очень простых операций файловая система определенно быстрее. Файловые системы, вероятно, также превзойдут СУБД в отношении сырой пропускной способности при чтении, поскольку затраты на нее меньше. Фактически, если вы подумаете об этом, база данных никогда не будет быстрее, чем файловая система, в которой она находится, с точки зрения сырой пропускной способности.

Для очень сложных операций файловая система, вероятно, будет очень медленной. Например:

Прочитайте 10 строк из этого файла с 1 миллиардом строк и затем найдите соответствующие строки в этом другом файле. Мне жаль тебя, если ты должен сделать это. Хороший сервер баз данных, тем не менее, имеет стратегии сделать это быстро и хорошо, так что вы не изобретаете велосипед.

Кроме того, вам действительно нужно выяснить, что вы делаете. Какие данные вы храните? Как вы собираетесь преобразовать это? Если это файлы изображений размером 100 тыс., Ваше решение будет выглядеть совсем иначе, чем если бы это был каталог для 100 тыс. Человек. (Возможно, LDAP? Или база данных SQL? Зависит от того, что вы делаете, возможно.) Ключевым моментом здесь является выбор инструментов, которые соответствуют тому, что вы делаете, и которые дают вам возможность добавить больше применений, а не то, что кажется самым быстрым для некоторых довольно абстрактный вариант использования. Базы данных - замечательные инструменты, но вы не можете получить хороший ответ на такой вопрос.

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

Файловая система может быть быстрее, но я сомневаюсь в этом. Однако по мере увеличения размера данных вам, вероятно, придется реструктурировать файловую систему для поддержания производительности. Помимо очевидной способности индексировать по нескольким атрибутам, базы данных, как правило, лучше масштабируются.

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

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

Я всегда люблю приходить на эти форумы и читать все тяжелые сообщения гуру баз данных о том, что файловая система не может сделать это так же быстро, как база данных. Напротив, правильно выстроенное дерево, хорошо спроектированные хеш-таблицы и сохранение их в виде объекта в файл будут давать те же скорости, что и база данных, и из моих тестов. Правильно спроектированная хеш-таблица и дерево каталогов будут побеждать каждый раз. Намного меньше накладных расходов. В последнее время я отошел от программирования на основе баз данных и больше от дерева файлов для простоты и переносимости программ. Отсутствие БД означает простое резервное копирование, просто заархивируйте дерево и работайте. Это очень приятно и рекомендуется программировать таким образом для бывших клиентов с небольшими приложениями. Посмотрите на большую картинку, есть ли у меня время, чтобы создать свой собственный или просто использовать то, что уже есть, например, БД. Мне лично нравится сохранять свои объекты в файл и использовать их позже, просто следите за размером ваших таблиц и изучите использование RandomAccessFile, чтобы иметь возможность быстро найти его в виде базы данных и разбить его на хеш-объекты , Наслаждаться. Помните, что когда-либо данные, которые вы храните в файле, будут использовать вдвое больше памяти, в зависимости от вашего кода. Сама хеш-таблица и, как правило, где вы ее используете для просмотра.