LINUX.ORG.RU

[php] Как лучше организовать текстовую базу


0

1

Сразу скажу, что задача написать простой «блог про себя», но мне нравится смотреть в сторону высокой нагрузки и производительности, поэтому затупил на первом этапе обдумывая стуктуры базы. Текстовой базы на файлах.

База хранится как массивы, в serialize формате, в файле с расширением .php (ниже узнаете зачем). Для чтения/записи написал две простые функции:

function array_get_contents($file) {
  if (file_exists($file)) {
    return unserialize(substr(file_get_contents($file), strlen('<?php exit; ?>')));
  }
  return NULL;
}

function array_put_contents($file, $data) {
  return file_put_contents($file, '<?php exit; ?>'.serialize($data), LOCK_EX);
}
P.S. а что лучше? f{open,read,write,close} или file_{put,get}_contents? Выбрал исходя из логики: чем меньше команд выполняет скриптовый интерпретатор, тем быстрее и лучше.

А теперь главное: посоветуйте, как лучше организовать структуру базы? Задачи: регистрация пользователей, добавление записей, к ним могут оставлять комментарии, имеется облако тэгов.

И сделать это хочу с учетом, что есть «мистический лимит» на количество файлов в одной директории (32000) (а есть ли на самом деле?), и что размер одного файла базы не должен превышать 2мб, т.к. боюсь, что постоянные записи/чтения файла чуть больших размеров php-скриптом не пойдут на пользу производительности.

Самое простое, что можно сделать, забив на лимиты:

array_put_contents(
  'data/notes/list.php', // список всех записок, простое ID
  array(
    0
  )
);

array_put_contents(
  'data/notes/0.php', // записка с ID 0
  array(
    'topic' => 'заголовок',
    'notes' => 'содержание',
  )
);
то есть, буквально храним список записей, и каждую запись отдельным файлом. Будет плохо, когда например количество записей будет 1,000,000 и list.php будет вешать десятки метров. Да и потом, вряд ли файловая система одобрит 1,000,000 файлов в одной директории? Конечно все это в теории, я в жизни не стану оставлять столько записей в блоге... И все же, у кого есть опыт проектирования баз, прошу помочь :)

P.S. В сторону SQL смотреть не буду - те же файлы, только в профиль. Впрочем вопрос не об этом, а о том, как стуктуировать базу, чтобы любой ее элемент можно было легко (с точки зрения производительности) достать, и она была максимум безлимитна. Как хранить файлы и т.д...

★★★★★

P.S. В сторону SQL смотреть не буду - те же файлы, только в профиль. Впрочем вопрос не об этом, а о том, как стуктуировать базу, чтобы любой ее элемент можно было легко (с точки зрения производительности) достать, и она была максимум безлимитна.

посмотреть в сторону самообразования, чтобы не пороть такую чушь

И да если sql не устраивает по объективным причинам, то использовать какую-либо nosql БД.

qnikst ★★★★★ ()

база на текстовых файлах не сделает твой говнокод хайлоадом

trashymichael ★★★ ()

В виде дерева.

Такая архитектура превратит любой блог в высоконагруженный проект. Узкие места: обращение к диску, попытка php помочь с оптимизацией, а на самом деле будет еще больше тормозов. Низкая надежность. Поиск?

SQL с самыми тормозными join запросами уделает такую базу, работая на смартфоне с андроидом.

note173 ★★★★★ ()

Почему бы сразу не генерить html-странички? В этом есть хоть какой-то смысл.

P.S. В сторону SQL смотреть не буду - те же файлы, только в профиль

Посмотри в сторону стены.

power ()

P.S. В сторону SQL смотреть не буду - те же файлы, только в профиль. Впрочем вопрос не об этом, а о том, как стуктуировать базу, чтобы любой ее элемент можно было легко (с точки зрения производительности) достать, и она была максимум безлимитна. Как хранить файлы и т.д...

http://demotivation.me/images/20090630/ltrys9mu4sis.jpg

PS. Тебе про LDAP тут уже сказали? Хотя, те же файлы, только сверху...

GateKeeper ★★ ()

Генерируй статические странички для каждой записи и главной. На регистрацию забей - есть Disqus.

Dragon59 ★★ ()

В сторону SQL смотреть не буду - те же файлы, только в профиль.

Впрочем вопрос не об этом, а о том, как стуктуировать базу, чтобы любой ее элемент можно было легко (с точки зрения производительности) достать, и она была максимум безлимитна.

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

и она была максимум безлимитна.

Что значит максимум безлимитна?

Tanger ★★★★★ ()

power, Dragon59

На сайте имеются места, где выводится информация типа «Ваш IP адрес», «Количество просмотров статьи» которая изменяется при каждом посещении.

Ладно, я избавлюсь от IP - ведь это не так актуально (хотя находилось на сайте лишь для, скажем так, создания атмосферы, подчеркивало дизайн).

Идея с генерацией HTML кода отличная, обязательно сделаю сайт статичным, насколько это будет возможно. И пусть «Количество просмотров статьи» пострадает, сделаю чтобы оно зависило не от клика, а от сессии. Тогда оно будет генерироваться реже.

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

Идея с «flat file» больше по душе, т.к. не нужно лишний раз заморачиваться с изучением языка запросов и оптимизировать их. Я уже устал от заморочек с оптимизацией кода ;)

Spoofing ★★★★★ ()
Ответ на: комментарий от Spoofing

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

Идея с «flat file» больше по душе, т.к. не нужно лишний раз заморачиваться с изучением языка запросов и оптимизировать их. Я уже устал от заморочек с оптимизацией кода ;)

Так чего ты хочешь-то?

power ()

Вопрос с базой решен, - делаю структуру такой, как сам же предложил в первом сообщении. Просто прикинул, что пускай есть лимит на 32,000 файлов в директории - ладно. Список-массив с ID в количестве 32,000 штук будет вешать всего 1мб, что очень даже хорошо. Далее, пусть я активно буду писать по 3 поста в день, это грубо говоря 1024 записей в год, итого мне такой базы хватит на 32 года, грубо говоря ;)

Я оказался слишком строг к своим требованиям, а оказывается не все так плохо. Всем спасибо. Прикручу к этому еще кэширование в HTML, и тогда сайт будет летать.

Spoofing ★★★★★ ()

В сторону SQL смотреть не буду - те же файлы, только в профиль

А тебя не смущает, что весь юникс - это те же файлы, только в профиль?

boombick ★★★★★ ()
Ответ на: комментарий от Spoofing

Идея с «flat file» больше по душе, т.к. не нужно лишний раз заморачиваться с изучением языка запросов

Вот и ответ, зачем ты такую фигню выдумал, ты просто SQL не знаешь. Потому как любому адекватному специалисту будет ясно, что сделать свою достаточно быструю СУБД (даже заточенную под какую-то узкую задачу) — задача очень нетривиальная.

Wizard_ ★★★★★ ()
Ответ на: комментарий от Spoofing

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

qnikst ★★★★★ ()
Ответ на: Блокировка ФС от RR

Ну зачем ты так сразу? Было бы интересно посмотреть тему «Куда пропадают данные в файлах?». Я лет 15 назад тоже по этим граблям поскакал :) Правда, у меня оправдание было — в те времена не было доступного SQL. А как появился, так я с текстовыми файлами работал уже только в особых случаях :)



Кстати, UltimateBB, отец классического современного вида форумов (аватарка сбоку, линейный вертикальный список сообщений — это, между прочим, непривычное новшество было!) и BB-кода был весь из себя на файлах :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от RR

ТС все равно проигнорировал

Наверное, просто не понял, о чём речь.

KRoN73 ★★★★★ ()

KRoN73, Вы про обнуление файлов, если их не блокировать? В функциях, которые я показал, есть LOCK_EX, поэтому расчитываю, что проблем не возникнет.

Остальным спасибо, но еще раз про SQL, - сейчас мне это не нужно. Я пишу первое веб-приложение, для себя, и вся цель с изобретением велосипедов^Wинструментов в том, чтобы чем-нибудь научиться. И при этом сразу беру «высокий пилотаж» - хочу хорошую производительность при большой нагрузке; уделяя большое внимание документации к любой используемой функции. Последним шагом будет хранить HTML страницы в tmpfs, но сперва еще нужно написать сайт на php.

Spoofing ★★★★★ ()
Ответ на: комментарий от Spoofing

В функциях, которые я показал, есть LOCK_EX, поэтому расчитываю, что проблем не возникнет.

Возникнет. Например, записать содержимое файла просто по fopen/flock/fwrite не получится. В момент, когда мы напишем fopen(...'w') файл обнулится будучи ещё не заблокированным. Параллельный процесс в этот момент считает пустой файл. Так что файл приходится открывать не разрушающе, блокировать его и только тогда — обнулять: http://trac.balancer.ru/bors-core/browser/inc/functions/fs/file_put_contents_...

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

chicane ()
Ответ на: комментарий от chicane

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

chicane ()
Ответ на: комментарий от chicane

тут же возникнут проблемы, когда во время записи в файл, например упадет php или система

Вот с таким ни разу в своей практике не сталкивался :) Я и не знал, что проблемы могут быть, думал, что при падении PHP файл сам разлочится системой.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

chicane ()
Ответ на: комментарий от power

Почему бы сразу не генерить html-странички?

+1

пиши руками каждую страницу в чистом HTML 4.01, на таблицах, без стилей, без функционала, только текст, только хардкор

q11q11 ★★★★★ ()
Ответ на: комментарий от q11q11

Смех смехом, а хорошая идея в качестве базы данных. Чтобы база хранилась в «веб 1.0» html файлах, - ее будет удобно читать с консольных браузеров и мобильных недоустройств. А для «веб 2.0» браузеров уже инклудилась в красивый дизайн основного сайта. И там, и там юзабилити будет на высоте. Ну и да, ручками править такой простой HTML-файл-базу не будет сложности. :)

Spoofing ★★★★★ ()
Ответ на: комментарий от q11q11

Повторюсь на счёт смех смехом, но я видел не так давно, то ли CMS, то ли форум, в котором данные прямо в .html и были :) При редактировании данные считывались и парсились из .html, при сохранении — заменялись.

А, вспомнил, это была чья-то самопальная CMS, да :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от q11q11

Ну зачем сразу руками. Я имел в виду автоматические генераторы (для гитхаба, например) :/

power ()
Ответ на: комментарий от q11q11

Только текст, только хардкор

пиши руками каждую страницу в чистом HTML 4.01, на таблицах, без стилей, без функционала, только текст, только хардкор

С использованием консольного редактора vim

Cypher ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.