Кей-валуе хранилище в файлах

XML? YAML? JSON?

Берёшь sqlite и используешь как key-value в файлах.

Медленно. Бессмысленно. На любом шареде?

Я не о формате файла (я вообще юзаю var_export для массива). Я о самой обвязке. О готовом полностью решении вместе c каким-нибудь API.

sqlite — медленно на 20 ключах?

Нет, для любителей nosql уже давно придумали berkeley db, но sqlite популярнее. Можно забить на файлы и заюзать memcached, в конце концов.

Ещё есть webscale™-решения вроде mongodb, но у них другой юзкейс

http://www.php.net/manual/en/ref.dba.php

sqlite — медленно на 20 ключах?

Медленно «подключение» к самой sqlite.

Нет, для любителей nosql уже давно придумали berkeley db, но sqlite популярнее. Можно забить на файлы и заюзать memcached, в конце концов.

На любом шареде. Важна переносимость.

Ещё есть webscale™-решения вроде mongodb, но у них другой юзкейс

Я обычно юзаю Redis - больше всех нравится. Но смотри ответ на цитату выше.

Уже интереснее. Но излишний функционал.

DBA уже не модно?

parse_ini_file говорили?

serialize/deserialize ;-)

Так у тебя теперь из-за велосипеда везде будет «излишний функционал».

Вот кстати... А почему serialize/deserialize а не просто var_export?

И лочить файл на время записи?

Это какой? Мне надо-то по сути - Get/Set/Save. Не нужны деревья, не нужны деревья, типы, и прочая ерунда. База данных она есть в любом случае и подключение к ней есть в любом случае и всё что надо в ней хранить в ней и хранится. Нужно предельно примитивное и быстрое.

И лочить файл на время записи?

С локом в DB, гг.

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

MongoDB? Хотя для твоих целей

хранить до 1-2 сотен ключей это потолок

это излишне наверное.

Не принципиально. Это скорее хранилище констант. Никто не пишет в него просто так. Ну вот смотри - надо вынести в настройки допустим телефоны организации и её адрес. Стандартно под это ничего не предусмотрено. Можно нагородить огород вокруг БД. Учитывая что в данном фреймоворке не принятно работать с БД напрямую и надо использовать API... Ну короче для вынимания телефона потребуется целый табор снаряжать за ним. Мне кажется это грустно.

Люди

Прыщавые школьники это не люди.

Кей-валуе хранилище в файлах (комментарий)

Переносимость. Я не подниму Mongo или Redis на первом попавшемся копеешном шареде.

Ну вот смотри - надо вынести в настройки допустим телефоны организации и её адрес. Стандартно под это ничего не предусмотрено.

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

Прыщавые школьники это не люди.

Правильно. Люди это те кто пихает сессии в базу и придумывает костыли для того чтобы реализовать жалкое подобие волатильных ключей? Я правильно понял?

Это скорее хранилище констант. Никто не пишет в него просто так. Ну вот смотри - надо вынести в настройки допустим телефоны организации и её адрес

1-2 сотен ключей это потолок

require_once('phone_and_address.php')

На любом шареде, никаких огородов.

То что выплевывает var_export очень легко редактировать руками. Но клиент хочет в «одминке» редактировать, видишь ли. Никак ему не объяснишь, что это надо руками делать. Хотя лично я так и делаю.

Shared memory тоже не подходит ?

Прекрасно. Теперь нужен интерфейс для редактирования этой бороды в админке CMS. Как?

Вообще говоря в этой CMS примерно так и сделано как ты написал. И потом имеем 150 инклюдов в 500 местах.

Я правильно понял?

Нет не правильно. Редис клевый, да.

И потом имеем 150 инклюдов в 500 местах.

spl_autoload ? Не, не слышал..

Никак ему не объяснишь, что это надо руками делать.

Опять не правильно понял. Редактируемость руками не означает невозможность править из гуя.

// Какой-то ты нервный сегодня. На работе что ли в Сб сидишь?

Не надо никаких лишних движений с парсингом. Просто читаешь-пишешь файл.

У него же категория - шаред. Т.е. тебе дают фтп и ты заливаешь файлики в папочку, ни тебе крона, ни ссш, о редисе речь просто не идет.

Хотя самый копеечный впс стоит столько-же но его надо еще и админить и настроить.

почему бы и нет? :-)

А где я советовал не шаред решение? Продай свисток, купи очки.

Люди

Прыщавые школьники это не люди.

Чем вам так люто не угодил редис?

Чем вам так люто не угодил редис?

Повторюсь, редис клевый. А вот школьники которые читать не умеют, раздражают, да.

У него же категория - шаред. Т.е. тебе дают фтп и ты заливаешь файлики в папочку, ни тебе крона, ни ссш, о редисе речь просто не идет.

Хотя самый копеечный впс стоит столько-же но его надо еще и админить и настроить.

У меня где-то 50 на 50 шаредов и vps/vds - штук по 10-15 каждого. Я имел ввиду «и на шареде тоже».

Перечитал дважды - никакого другого вывода кроме того, что по твоему мнению редис используют прыщавые школьники, не сделал. Что же ты хотел сказать?

но хотелось бы узнать существующие решения на пыхе есть какие?

http://www.php.net/manual/en/book.dba.php

А хотя уже назвали, да.

Сериализация либо сразу код пишешь в файл. Тред не читал.

fileputcontent(json_encode($db));

file_put_contents(json_encode...)
json_decode(file_get_contents...)

Какой Капитан морган? Какое API? Какая обвязка? Если так нравятся обвязки — иди в джаву, пиши там фабрики фабрик абстракций

Berkeley DB уже вспоминали? В частности версию 1.85 — быстро, надёжно, глобоально.

sqlite, berkeleydb

Кейс примитивный - хранить до 1-2 сотен ключей это потолок

Самый быстрый способ — serialize/unserialize ( http://www.balancer.ru/g/p3304960 ) и читать всё в память. Только при записи надо не бывать лочить файл, а то на параллельной работе легко поймать его повреждение.

Более «честный» и без внешних сервисов (я понял вопрос в этом?) — использовать embedded, типа leveldb или хотя бы sqlite. Первое быстрее, второе — чаще стоит на говнохостингах.

Вот кстати... А почему serialize/deserialize а не просто var_export?

См. ссылку на бенчмарк в предыдущем моём постинге :)

А если скорость не важна, то лично я выбираю JSON. Он читается хорошо :)

А в варианте с голым key=value, ещё красивее использовать .ini — и скорость, как у var_export/eval, и human readable полный.

Кейс примитивный - хранить до 1-2 сотен ключей это потолок. По факту пара десятков.

разве тебе недостаточно обычного массива php?

Только при записи надо не бывать лочить файл, а то на параллельной работе легко поймать его повреждение.

в данном случае даже этого не нужно, т.к. ТС говорил, что это какие-то телефоны в какой-то админке. Неужели у него на редактирование 20и телефонов выделено более одного одмина?!

Мне важна полная переносимость. Как я сказал у меня сейчас более 20 проектов на совершенно разных хостингах и решение работать должно везде. За измерение производительности спасибо - большая часть работы проделана, осталось сравнить unserialize(file_get_contents('serialize.dat')) vs include($path) - потому что я делаю сейчас именно так сохраняя в файл сразу self::$__currentBase=array(); если будет не на много дльше - заюзаю его - это решает кое-какие проблемы.