- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Разрабатываю простенький сайт для отображения данных с простой структурой.
Объем данных примерно 5000-10000 записей размером 1-3 кбайт, то есть всех данных точно меньше 50-100 мегабайт.
Можно ли при таких условиях обойтись без базы данных и хранить данные как сериализованные массивы в файлах? Какие есть подводные камни такого решения?
База данных != MySQL, есть и более миниатюрные релизации. Все сводится к тому, что скрипт будет делать с этими данными, если нужны представления в различных срезах и т.п., то придется, по сути, городить свою реализацию подобия БД, что нафиг не нужно.
Для такого размера данных я бы использовал исключительно MySQL. Во-первых, быстрее, во-вторых, просто удобнее. Да и мало ли, что впереди ждёт сайт, может быть, придётся админку под него делать али ещё что полезное. Поэтому, всё же не стоит лениться и переведите данные в мускул.
если нужны представления в различных срезах и т.п., то придется, по сути, городить свою реализацию подобия БД, что нафиг не нужно.
Да, это я понимаю. В том то и дело что ничего кроме выборки по ключу не надо. То есть структура данных такая: [key] -> [value].
Пхпшный массив отлично подходит для быстрой выборки по ключу, быстрее не надо.
Поэтому и думаю хранить все как сериализованный массив в файле. Но не уверен что прокатит)
ppch, подумайте о способах сохранения целостности файлов, коллизиях и накладных расходах.
Уже не так просто получается. Может, лучше готовый интерфейс?
Возможно и можно. Но лучще sqlite тогда уже.
подумайте о способах сохранения целостности файлов, коллизиях и накладных расходах.
целостность файлов не критична, это просто viewer, эталон данных хранится в другом месте.
коллизий быть не может доступ только на чтение.
накладные расходы вижу в необходимости серверу поднимать в память весь массив с диска при каждом обращении - можно порешать кэшированием в памяти, если будет критично.
ppchМожет, лучше готовый интерфейс?
Денех жалко. Сайтик этот будет жить во множественных экземпялрах на разных доменах.
Да и не вижу особого смысла преобразовывать данные в формат таблиц баз данных а потом при поиске опять формировать тот же самый пхпшный массив. Это кстати тоже накладные расходы.
---------- Добавлено 10.10.2014 в 08:43 ----------
Но лучще sqlite тогда уже.
sqlite надо чтобы на хостинге был, и там тоже как-бы файл базы данных формируется, который надо хранить и заботится о его целостности.
учитывая что данных мало и запросы простые... не вижу особого смысла заморачиваться.
в инете где-то была да CMS примерно в 100кб, которая работает без базы, и все информация хранится в текстовых файлах.
То есть структура данных такая: [key] -> [value].
Пхпшный массив отлично подходит для быстрой выборки по ключу, быстрее не надо.
Поэтому и думаю хранить все как сериализованный массив в файле. Но не уверен что прокатит)
Не лучшая идея. Посчитайте сколько займет места сериализованный массив: исходные данные + накладные расходы на сериализацию. И этот массив при каждом чихе(обращении к сайту) нужно будет полностью считывать в память, чтобы достать одну страничку.
Про модификацию данных молчу - придется делать какую-то админку и проверку на целостность файла при сохранении, а то место закончится - и оп-с сайта уже нет.
Если все-таки решитесь так делать, то можете разбросать данные по 16 или 256 сериализованным массивам, т.е. будет 16 или 256 файлов данных. Малость геморойно, но работать быстро будет.
Определить в какой файл лезть: берете один или два симола от функции md5($key).
Стремный подход... но для гавников на фрихостах может и покатит. :)
Посчитайте сколько займет места сериализованный массив: исходные данные + накладные расходы на сериализацию. И этот массив при каждом чихе(обращении к сайту) нужно будет полностью считывать в память, чтобы достать одну страничку.
Уже посчитал - максимум 100 мегабайт с учетом расходов на сериализацию.
Расходы на закачку в память массива можно легко решить memcache'м.
Про модификацию данных молчу - придется делать какую-то админку и проверку на целостность файла при сохранении, а то место закончится - и оп-с сайта уже нет.
Только чтение, модификации нет.
Если все-таки решитесь так делать, то можете разбросать данные по 16 или 256 сериализованным массивам, т.е. будет 16 или 256 файлов данных. Малость геморойно, но работать быстро будет.
Определить в какой файл лезть: берете один или два симола от функции md5($key).
Стремный подход... но для гавников на фрихостах может и покатит. :)
Подход хороший, думал об этом, спасибо.
Вам нужно key -> value.
Так возьмите простенькие типа Redis, Memcached и их подобных - быстрые удобные и подходит под Ваши запросы.
Можно спокойно и обойтись без базы.
Но например скорость чтения и записи будет крайней мала.