Чем отличается база данных от файла
Обновлено: 02.07.2024
база данных в конечном счете хранит данные в файлах, тогда как файловая система также хранит данные в файлах. В этом случае в чем разница между БД и файловой системы. В том, как его извлекают, или в чем-то еще?
база данных обычно используется для хранения связанных структурированных данных с четко определенными форматами данных эффективным способом для вставки, обновления и/или извлечения (в зависимости от приложения).
С другой стороны, файловая система является более неструктурированные хранилища данных для хранения произвольных, наверное, лишнее. Файловая система является более общей, и базы данных построены поверх общих служб хранения данных, предоставляемых файловыми системами. [Quora]
файловая система полезна, если вы ищете конкретный файл, а операционные системы поддерживают своего рода показатель. Однако содержимое файла txt не будет индексироваться, что является одним из основных преимуществ базы данных.
для очень сложных операций, файловая система, вероятно, будет очень медленным.
основные преимущества РСУБД:
таблицы связаны друг с другое
SQL query / язык обработки данных
добавление обработки транзакций в SQL (Transact-SQL)
реализация сервера-клиента с объектами на стороне сервера, такими как хранимые процедуры, функции, триггеры, представления и т. д.
преимущество файловой системы над системой управления базой данных:
при обработке небольших массивов данных с произвольным, наверное несвязанные данные, файл более эффективен, чем база данных. Для простых операций чтение, запись, файловые операции выполняются быстрее и проще.
вы можете найти n количество различий через интернет.
что-то нужно знать о том, что Unix имеет то, что называется пределом индекса. Если вы храните миллионы записей, это может быть серьезной проблемой. Вы должны бежать df -i для просмотра % используется как эффективно это ограничение файла файловой системы-даже если у вас есть много места на диске.
разница между системой обработки файлов и системой управления базами данных заключается в следующем:
система обработки файлов представляет собой набор программ, которые хранят и управляют файлами на жестком диске компьютера. С другой стороны, система управления базами данных-это набор программ, позволяющих создавать и поддерживать базу данных.
система обработки файлов имеет больше избыточности данных, меньше избыточности данных в СУБД.
Вообще, что такое база данных!? Это, по сути, те же файлы. Ведь физически они где-то храниться должны.
А кроме файлов, физической оболочки просто не существует! Как бы странно это ни звучало!
Только отличие файла от базы данных в способе обработки !
Кроме того!
Существуют базы данных, которые и позиционируются, что не требуют отдельного сервера, например → SQLite
По сути, это таже база данных, но только в файле, который может лежать в любой папке вашего сайта.
Я не против и не за базы данных!
Поскольку я не пользуюсь базами данными выше перечисленными, то и о преимуществах и недостатках ничего вам не могу сказать!
Но зато! Я 5 лет пользуюсь файлом в качестве базы данных. Одна строка - одна статья (формат файла ".dat").
Скоро - может даже сегодня, напишу(давно надо было сделать это), как можно хранить данные вашего сайта даже и без SQLite - это вообще самый, самый, самый простой способ! И если бы данный способ, как-то меня не устраивал, то я давно бы искал бы альтернативу!
Единственное -может, если ход дойдет, то для будущих статей буду изучать "SQLite"(но это не точно!) .
Почему я выбрал файл вместо базы данных!?
Базы данных придумали не просто так! И для большого проекта - скорее всего нужно использовать базу данных вместо файла.
Но когда вы собираетесь делать авторский сайт, блог, то база данных - это просто. ну не знаю.
Вам нужно перевести 10 кг груза и вы нанимаете Белаз грузоподъемность 120.000кг
Авторский сайт на файлах или на базе данных?
Мне не нравятся люди, которые нахватались верхушек и пытаются выдать себя за "гуру"! Я не ГУРУ, но я занимаюсь своим сайтом, который полностью построен на файлах и немного понимаю в файлах. Никаких предпосылок, что я собираюсь задумываться над переходом на базу данных с файлов.
Просто. частенько вижу в интернете категорические высказывания типа: "Сайт на файлах отстой и т.д. и т.п." - важно не на чём ваш сайт построен! А какой контент ! Это самое главное, что вам следует запомнить!
И это именно то, что вы сейчас видите вокруг и давайте попробуем разобраться. "Авторский сайт на файлах" или на базе данных!?
Предположим , что вы хотите сделать свой собственный авторский сайт(это моя история).
Естественно -самое простое - хранение данных в файле!
Давайте попробуем посчитать на пальцах емкость файла - ведь нам нужно знать, сколько статей вы сможете написать , прежде, чем файл станет неподъемным!
Будут существовать два вида файлов:
Естественно - в файле базы данных, сами статьи не будут хранится, а лишь краткая информация о странице(формат хранения, либо построчно, либо в ассоциативном массиве), чтобы вывести например их в виде списка.
А контент будет храниться в отдельных файлах - одна статья - один файл.
Сколько строк максимально для такого файла?
Специально провел эксперимент лет несколько назад. на сервере установлен максимальный размер файла, сейчас точно не помню, по моему 13мб - это можно узнать(не проблема.)
И только после 500.000 строк максимальный разрешенный объем файла был пройден!
Сколько статей в день!?
Предположим, что вы зададите себе план - 1 статья в день!
Поверьте мне на слово - что это не так просто сделать, как кажется! Насколько я упертый, даже я не смог этого сделать, за все время существования данного проекта, всего дней : - 2184 дня .
И если мы разделим количество статей, на данный момент 915 , на выше приведенное количество дней, то получим:
4 статьи в 10 дней. (0.41895604395604)
P.S. если интересно смотри счетчик сколько статей в день php
Вы сможете поддерживать ритм 1 статья в день на протяжении множества лет, то чтобы превысить барьер в 500.000 строк, вам понадобится
500.000 / 365 = 1369лет
Вы сможете писать 10 статей! Здесь, я как доктор говорю, что это! невозможно для 1 человека.
Но, даже, если это чудо произойдет, то вам все равно понадобится:
500.000 / 3650 = 137лет
Зачем это я вам все рассказываю!? К тому, что файл вполне подходит для создания личного сайта.
Основные параметры базы данных в файле.
Чтобы не разводить теорию, сразу притупим к основным параметрам и (скоро будет отдельная тема(надеюсь) движок на файлах.)
Всего будет два файла:
1). Где будем хранить данные о странице?
Файл базы данных(формат файла ".dat"), где будет краткая информация о странице.
Формат хранения ассоциативный массив. Первая версия была построчно
Сейчас - думаю нет необходимости останавливаться на этом подробно.
2). Где будем хранить контент?
Формат файла - здесь есть варианты. Сейчас использую ".html", но в будущем движке хочу также перейти на ".dat", но выводиться будет в адресной строке ".html" - это возможно когда у вас единая точка входа
Формат хранения контента в файле - сейчас в переменных(в этом способе есть свои плюсы и минусы!), но в движке будем хранить в массиве. В чем разница?
Это мы накидали только часть того, что касается базы данных + бонус немного о страницах.
Если мы начнем говорить о движке, то это не просто много, а очень много тем. Поэтому, будет отдельная страница!
Файл + ассоциативный массив.
Вид такого массива будет, если мы его выведем через print_r :
[title] => База данных или файл данных
[description] => Хранение данных база или файл?
В чем удобства именно такого хранения данных.
Мы спокойно можем добавить любой элемент в ячейку.
Удаление ячейки происходит до банальности скучно.
В общем больше не буду перечислять, как можно взаимодействовать с ассоциативным массивом..Создаем уникальный "ИД"
Вы соберетесь изменить адрес данной страницы, то ваш "ИД" в ассоциативном массиве автоматически поломается!
Как решить такую проблему. Т.е. если ваша страница изменила адрес, то значит её по старому адресу нет. У меня это процесс происходит таким образом.
Копируем содержание страницы.
Удаляем страницу + автоматически удаляется ячейка в массиве.
Создаем новую страницу(вставляем скопированный контент) с новой записью в массиве.
Как и что, будем хранить данные в файле .dat
После того, как мы получили уникальный "ИД" - $page_id, который и будет главной ячейкой для страницы:
Если вы обратите внимание на ниже идущую первую строчку, то вы должны спросить - зачем там условие!
Это для того, если массив еще не существует, т.е. не создана еще ни одна страница, то создаем пустой массив.
Ну а если массив существует, то php вовнутрь по этому условию не зайдет.
Без данного условия, при каждой отправке данных на запись, массив создавался пустой, с единственной записью. И так каждый раз.
Процесс создания структуры массива с данными:
Если вы обратите внимание на ниже идущую первую строчку, то вы должны спросить - зачем там условие! Это для того, если массив еще не существует, т.е. не создана еще ни одна страница, то создаем пустой массив. Ну а если массив существует, то php вовнутрь по этому условию не зайдет. Без данного условия, при каждой отправке данных на запись, массив создавался пустой, с единственной записью. И так каждый раз.
Записываем название массива, это переменная :
Вторым элементов с троке идет уникальный ид ячейки - это переменная(т.е. таким образом переменной можно присвоить любое значение.) :
И третьим идет ключ внутри ячейки:, он может использоваться без кавычек в тмо случае, если в ключе нет пробела.
$example_main_array[$page_id][title] = 'База данных или файл данных';
$example_main_array[$page_id][description] = 'Хранение данных база или файл?';
$example_main_array[$page_id][author] = 'Марат';// Если это будет авторский блог , то данная ячейка не нужна!
Вывод ячейки массива на экран с помощью print_r
Выведем первую ячейку, которая у нас получилась:
[title] => База данных или файл данных
[description] => Хранение данных база или файл?
Как будем записывать и получать данные из файла
В данном пункте, хочу обратить ваше внимание!
Что запись будет производиться "ВСЕГДА" в конец массива. Но нам нужно, чтобы свежая запись всегда была сверху. Просто, чтобы не мучаться с реверсом при выдаче, лучше помучаться с реверсом при записи!
Собака "@" нужна для того, чтобы при не существующем массиве, не выдавало ошибку.
Из нашего будущего файла "$dir_rotate" - путь естественно должен быть на сервере
Нам понадобится функция unserialize
Переменная "$reverse_ok" - нам понадобится ниже, - надеюсь по названию понятно почему!? Чтобы развернуть массив.
Ниже. тот массив, который мы создавали. в предыдущем пункте.
$example_main_array[$page_id][title] = 'База данных или файл данных';
$example_main_array[$page_id][description] = 'Хранение данных база или файл?';
Далее проверяем был ли перевернут массив $reverse_ok, если да, то возвращаем в нормальное направление
Нам нужна строка, поэтому превратим массив в строку - serialize
$write_for_main = @file_put_contents($dir_rotate, serialize($example_main_array));
Соберем весь код вместе:
$example_main_array[$page_id][title] = 'База данных или файл?';
$write_for_main = @file_put_contents($dir_rotate, serialize($example_main_array));
Форма ввода для записи в файл .dat
Нам нужна форма для записи данных в базу в файле .dat, какие данные будем записывать!?
Дату - создания записи - date('d.m.Y').
Картинка, либо будет загружаться новая, или же соответствует папке, в которой будет создаваться новая страница. Если вы думаете, что на каждую новую страницу будете делать новую картинку, то к 10-20 странице вам надоест! Поэтому рекомендую на каждую подтему создать картинку, и чтобы она автоматически загружалась. Чтобы не мучаться, сделаем как у меня на сайте. А уж если вы захотите. то сами измените, так, как вам надо.
Далее два поля, изменим название ячеек в соответствии с "POST", чтобы потом не путаться! - поскольку они обязательны required, то никаеи условия можно не писать.
$example_main_array[$page_id][title_for_main] = $_POST['title_for_main'];$example_main_array[$page_id][description_for_main] = $_POST['description_for_main'];
Насчет ячейки авторства, если мы говорим, об авторском сайте, то это не обязательно.
Две ячейки и [url] - на них остановимся на отдельных страницах, потому, что в двух словах тут не получится.
Что же будет, если хранить каждый материал в отдельном файле, и алгоритмами доставать данные? Чисто теоретически, будет ли это быстрее базы данных?
361 1 1 золотой знак 5 5 серебряных знаков 13 13 бронзовых знаков 1,605 2 2 золотых знака 28 28 серебряных знаков 58 58 бронзовых знаковосновная проблема файлов - это открытие сразу всего, и выдирание нужного, из-за чего теряется скорость, потому что объём загрузки большой.
Нет, не это :) Совсем не обязательно всё хранить внутри файлов, "эмулирующих" БД. Хранить там можно, например идентификаторы файлов с контентом, а сами данные вынимать из них по мере необходимости.
А вот относительно сложная логика работы - это уже проблема. Без БД можно задолбаться с какой-нибудь выборкой по непростому условию, да с джойнами, на с груп бай, которая в SQL делается одной левой.
В качестве любопытного примера можно посмотреть, например, на GetSimple CMS. Там всё организовано в виде XML-хранилищ, ничё, живёт и даже работает :)
Все зависит от способа работы с данными.
Предположим, что данные - это тяжелые изображения (bmp, tiff и т.п.), каждое изображение характеризуется уникальным именем (xxx.xxx). Предположим, что обращение к изображению всегда осуществляется по этому имени. Нужна ли в этом случае какая-либо особенная база данных?
SQL-база данных не нужна, потому что не нужен язык запросов; NoSQL-база может быть и нужна, а может быть и не нужна: в самом деле, обращение к файлу по имени в подходящей файловой системе (xfs) достаточно быстро, операционная система может сама кэшировать часто извлекаемые файлы в памяти.
Необходимость в базе возникает тогда, когда появляется потребность в чем-либо сверх того минимума, который дает файловая система.
Есть так называемая SQLite бд, она хранит бд в отдельном файле, из названия понятно что она поддерживает язык SQL. Работать с ней достаточно легко, в каждом языке программирования есть драйвера для работы с ней, в отличие от других SQL баз она не требует отдельного демона.
Я не просил порекомендовать БД, которая хранит всё в одном файле.Угу файлы, хочу достать всех учеников закончивших школу в 96 году, с тройкой по географии и остававшихся на второй год. Имею папку в которой лежит 1500 файлов. Каждый файл = записи об одной школе. Вы теперь предлагаете самостоятельно писать парсер/регэкспить это, а не написать двухстрочный Select, который вызовет уже написанный алгоритм поиска на сервере, который уже лет 30 оптимизируют огромная толпа программистов по всему миру.
Делаю сервис, будет храниться несколько версий файлов, плюс, таких изначальных файлов предполагается что будет немало. На данный момент я рассчитываю ориентировочно на пару тысяч файлов (в итоге), но в перспективе количество файлов может быть и больше.
— где лучше хранить все эти файлы — в виде Blob/text в MySql или же в виде отдельных файлов на диске? Сами файлы напрямую клиентам отдаваться не будут — сначала они обрабатываются специальным php скриптом и только потом результат обработки отдается. Для каждого клиента результат может быть разным (а может быть и таким же)
— как лучше все это потом бэкапить? Есть подозрение что все эти тысячи файлов бэкапить будет тяжко, если не хранить их в базе данных…
На самом деле оба варианта по реализации настолько минимально отличаются, что хорошим советом будет «сделайте сейчас оба варианта, используйте сначала файлы, а когда файлов будет много померяете производительность».
В 99% случаев файлы лучше, т.к. к ним есть прямой и очевидный доступ без всяких баз, а база в любом случае прослойка.
По бакапам ситуация двоякая, с одной стороны файлы удобнее бакапить тем же инкриментом и обычными файловыми средствами, с другой стороны разовый бакап базы сделать можно сделать просто скопировав файл с таблицей и не надо собирать кучу файлов.
По скорости/нагрузке, безусловно если это один сервер, то файлы будут побыстрее (только бейте на папки, не пихайте больше 1000 в одну в любом случае), но если у Вас несколько серверов, то отдельный сервак с базой под файлы может иметь определённые преимущества, доступ к базе по сети чуть более очевиден (хотя если у Вас есть админ, то не принципиально).
Файлы при прочих равных однозначно лучше попадают в кэш, с другой стороны засирание кэша базой проще контроллировать.
Не совсем. На БД проще сделать HA и репликацию — абстракция от файлов же. Если делать на файлах то надо думать как сделать их доступными (если надо) и реплицию. Однако, если принять во внимание, что ФС это тоже БД то различия почти минимальны.
Может автору лучше вообще сам себе Amazon S3 сделать? или Luwak + Riak или CouchDB или Riak CS.
Единственное преимущество хранения файлов в БД, на которое нужно обратить внимание — это конкурентный доступ. То есть СУБД корректно обрабатывает одновременный доступ на изменение к одной и той же записи. Если конкурентный доступ маловероятен, то лучше использовать файлы.
Преимущество файлов:
— Бэкапить файлы не намного дольше, но восстанавливать можно по отдельным файлам, а не заливать весь дамп.
— Обращение к файлам и считывание быстрее, чем получение записи из БД (даже если используются сокеты).
— Кэширование файлов осуществляет автоматически ОС и сервер (можно использовать и опкэшер для контроля). А у СУБД кэширование больших файлов вызывает потерю производительности из-за вытеснения простых запросов из кэша.
— Количество файлов может быть очень большим без потери мощности сервера. У меня один раз хранилось около 12000 файлов в одной директории и ничего — сервер считывал без всяких задержек. Конечно вручную открыть эту папку было проблемно.
— Sphinx — свободно ищет по файлам.
Но при всех преимуществах файлов конкурентный доступ может испортить всю «малину», так что отталкивайтесь от него.
Когда у меня встала задача хранить 2млн HTML файлов, много чего перепробовал. Только у меня архив один раз формировался а потом в режиме read-only раздавался с помощью веб-сервера Tornado.
Остановился на SQLite + gzip. Т.е. создал таблицу с полями (name, blob) и каждый HTML сжимал в gzip.
В SQLite отключил синхронную запись для ускорения заполнения.
Успел попробовать bsd btree, bsd hash, gdbm, json-lines, csv ну и просто иерархия файлов на диске. Хотел попробовать tokyo cabinet, но не нашел драйверов для Python.
bsd btree в принципе сравнима с SQLite по скорости, но занимает больше места на диске и менее гибкое. json-lines занимает гораздо больше места, csv (и json тоже) нельзя упаковать в gzip и не поддерживает доступ по ключу.
Просто набор файлов на ФС — крайне неудобно для бэкапов и трудно с ними работать, например рекурсивное удаление занимает несколько часов.
gzip vs не gzip — однозначно gzip! Мало того, что «сжать в gzip и записать на диск» — быстрее чем просто «записать на диск», так ещё и место сэкономите.
Читайте также: