Обойтись без MySql?

12
P
На сайте с 17.04.2006
Offline
71
1418

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

Объем данных примерно 5000-10000 записей размером 1-3 кбайт, то есть всех данных точно меньше 50-100 мегабайт.

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

Joker-jar
На сайте с 26.08.2010
Offline
123
#1

База данных != MySQL, есть и более миниатюрные релизации. Все сводится к тому, что скрипт будет делать с этими данными, если нужны представления в различных срезах и т.п., то придется, по сути, городить свою реализацию подобия БД, что нафиг не нужно.

Оказываю услуги веб-программиста и администратора Linux. ICQ: 751355 | Jabber: jokerjar@jabber.ru | Skype: joker-jar
Casan
На сайте с 10.10.2014
Offline
3
#2

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

PHP-скрипты, создание сайтов, разработка интернет-магазинов, парсеров и т.д. (/ru/forum/869424)
P
На сайте с 17.04.2006
Offline
71
#3
Joker-jar:
если нужны представления в различных срезах и т.п., то придется, по сути, городить свою реализацию подобия БД, что нафиг не нужно.

Да, это я понимаю. В том то и дело что ничего кроме выборки по ключу не надо. То есть структура данных такая: [key] -> [value].

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

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

DV
На сайте с 01.05.2010
Offline
644
#4

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

Уже не так просто получается. Может, лучше готовый интерфейс?

VDS хостинг ( http://clck.ru/0u97l ) Нет нерешаемых задач ( https://searchengines.guru/ru/forum/806725 ) | Перенос сайтов на Drupal 7 с любых CMS. ( https://searchengines.guru/ru/forum/531842/page6#comment_10504844 )
foxi
На сайте с 02.03.2011
Offline
880
#5

Возможно и можно. Но лучще sqlite тогда уже.

Антибот защита для сайта (https://antibot.cloud/ru.html#searchengines) (защита от кражи контента и спама) | ВебМастерские микроблоги (https://wmsn.biz/#searchengines) | Фокси SEO форум (https://foxi.biz/#searchengines)
P
На сайте с 17.04.2006
Offline
71
#6
DenisVS:
подумайте о способах сохранения целостности файлов, коллизиях и накладных расходах.

целостность файлов не критична, это просто viewer, эталон данных хранится в другом месте.

коллизий быть не может доступ только на чтение.

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

DenisVS:
ppchМожет, лучше готовый интерфейс?

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

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

---------- Добавлено 10.10.2014 в 08:43 ----------

foxi:
Но лучще sqlite тогда уже.

sqlite надо чтобы на хостинге был, и там тоже как-бы файл базы данных формируется, который надо хранить и заботится о его целостности.

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

G
На сайте с 04.01.2012
Offline
35
#7

в инете где-то была да CMS примерно в 100кб, которая работает без базы, и все информация хранится в текстовых файлах.

всегда готов помочь, за недорого, если что-то сделать не получается. беру на обслуживание сайты на постоянной основе. установка скриптов и модулей, обновление, принимаю благодарности в любом виде
A
На сайте с 19.07.2010
Offline
130
#8
ppch:
То есть структура данных такая: [key] -> [value].
Пхпшный массив отлично подходит для быстрой выборки по ключу, быстрее не надо.
Поэтому и думаю хранить все как сериализованный массив в файле. Но не уверен что прокатит)

Не лучшая идея. Посчитайте сколько займет места сериализованный массив: исходные данные + накладные расходы на сериализацию. И этот массив при каждом чихе(обращении к сайту) нужно будет полностью считывать в память, чтобы достать одну страничку.

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

Если все-таки решитесь так делать, то можете разбросать данные по 16 или 256 сериализованным массивам, т.е. будет 16 или 256 файлов данных. Малость геморойно, но работать быстро будет.

Определить в какой файл лезть: берете один или два симола от функции md5($key).

Стремный подход... но для гавников на фрихостах может и покатит. :)

.............
P
На сайте с 17.04.2006
Offline
71
#9
admak:
Посчитайте сколько займет места сериализованный массив: исходные данные + накладные расходы на сериализацию. И этот массив при каждом чихе(обращении к сайту) нужно будет полностью считывать в память, чтобы достать одну страничку.

Уже посчитал - максимум 100 мегабайт с учетом расходов на сериализацию.

Расходы на закачку в память массива можно легко решить memcache'м.

admak:

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

Только чтение, модификации нет.

admak:

Если все-таки решитесь так делать, то можете разбросать данные по 16 или 256 сериализованным массивам, т.е. будет 16 или 256 файлов данных. Малость геморойно, но работать быстро будет.
Определить в какой файл лезть: берете один или два симола от функции md5($key).
Стремный подход... но для гавников на фрихостах может и покатит. :)

Подход хороший, думал об этом, спасибо.

W
На сайте с 02.10.2014
Offline
8
#10

Вам нужно key -> value.

Так возьмите простенькие типа Redis, Memcached и их подобных - быстрые удобные и подходит под Ваши запросы.

Можно спокойно и обойтись без базы.

Но например скорость чтения и записи будет крайней мала.

12

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий