Узнал что DocuWiki на файлах и вроде как популярна
Спустя 12 минут, 22 секунды (26.09.2009 - 10:16) Guest написал(а):
если сначала и будет быстрее(и то не факт), то при увеличении объёма базы - станет медленнее
Спустя 5 минут, 14 секунд (26.09.2009 - 10:21) WhiteKnight написал(а):
Спустя 1 минута (26.09.2009 - 10:22) glock18 написал(а):
WhiteKnight
зависит от того ЧТО хранить в бд и файлах.
допустим, если в бд хранить исходники скриптов, то очевидно на файлах будет быстрее.
в общем, всему свое применение. любой нормальный использует и то, и то.
зависит от того ЧТО хранить в бд и файлах.
допустим, если в бд хранить исходники скриптов, то очевидно на файлах будет быстрее.
в общем, всему свое применение. любой нормальный использует и то, и то.
Спустя 12 минут (26.09.2009 - 10:34) Nikitian написал(а):
Быстрее, медленнее - не в этом направлении думать надо. Подумайте как вы будете делать какие-либо выборки из файла при неточном поиске (условия больше, меньше, полнотекстовый поиск) - это же жесть, придётся перебирать все данные. По-сути, та же mysql тоже на файлах (кроме таблиц типов heap & memory), но во-первых чтение этих файлов происходит не при каждом запуске клиентского скрипта, а по необходимости, а во-вторых, если будете писать движок индексов для файлов, то получится та же бд, но к тому времени вы уже поймёте, что бд, основанную на демоне использовать куда выгоднее, чем изобретать свои велосипеды. А уж прикручивание парсера sql-запросов навсегда у вас отобъёт желание так извращаться.
Спустя 13 минут, 56 секунд (26.09.2009 - 10:48) WhiteKnight написал(а):
Значит с ростом оно все станет прожерливей к ресурсам и потом просто будет не работоспособно что ли ?
Спустя 2 часа, 51 секунда (26.09.2009 - 12:49) FatCat написал(а):
Почему нужно выбирать одно?
Лично я совмещаю оба варианта в одном движке. В частности, в этом форуме мной сделан модуль раздельного хранения информации. Сообщения свыше 4 000 знаков хранятся в файлах, короткие сообщения хранятся в БД. При желании вручную можно переопредеить место хранения каждого сообщения.
Лично я совмещаю оба варианта в одном движке. В частности, в этом форуме мной сделан модуль раздельного хранения информации. Сообщения свыше 4 000 знаков хранятся в файлах, короткие сообщения хранятся в БД. При желании вручную можно переопредеить место хранения каждого сообщения.
Спустя 1 час, 14 минут, 37 секунд (26.09.2009 - 14:04) sergeiss написал(а):
FatCat - одно дело конкретные сообщения 
Они же не читаются постоянно разными пользователями. И уж, тем более, не апдейтятся постоянно.
А у ТС вопрос, как я понимаю, больше именно о создании своей БД. Хоть он и не такими словами выражается, но он к этому придет. И в итоге получит то, о чем писал Nikitian.
Они же не читаются постоянно разными пользователями. И уж, тем более, не апдейтятся постоянно.А у ТС вопрос, как я понимаю, больше именно о создании своей БД. Хоть он и не такими словами выражается, но он к этому придет. И в итоге получит то, о чем писал Nikitian.
Спустя 6 минут, 17 секунд (26.09.2009 - 14:10) WhiteKnight написал(а):
Да, я имел ввиду. Полностью создание форума использующие текстовые файлов или SQL сервер (если я правильно выразился) как БД.
Спустя 20 минут, 39 секунд (26.09.2009 - 14:31) sergeiss написал(а):
WhiteKnight - лучше потрать 3 часа на изучение основ работы с БД. Иначе ты придешь (как уже было сказано ранее) к созданию своей БД. Которая все равно будет работать хуже, чем любая другая.
А простые файлы выгоднее использовать либо для хранения данных, которые не изменяются (или изменяются очень редко), или для хранения отдельных сообщений из форума (как сказал FatCat). Собственно говоря, второй вариант - это как раз хранение неизменяемых (редко изменяемых) данных. А ссылка на это сообщение все равно лежит в БД.
А простые файлы выгоднее использовать либо для хранения данных, которые не изменяются (или изменяются очень редко), или для хранения отдельных сообщений из форума (как сказал FatCat). Собственно говоря, второй вариант - это как раз хранение неизменяемых (редко изменяемых) данных. А ссылка на это сообщение все равно лежит в БД.
Спустя 4 минуты, 10 секунд (26.09.2009 - 14:35) WhiteKnight написал(а):
sergeiss
Конечно, я не против БД. Учу сейчас их.
Просто вот нашел такие проекты на текстовых файлах и удивился как они там все организовали и собираются все это поддерживать.
Я уже писал гостевую на файлах и на БД и заметил, что с БД во много раз удобней и приятней работать.
Конечно, я не против БД. Учу сейчас их.
Просто вот нашел такие проекты на текстовых файлах и удивился как они там все организовали и собираются все это поддерживать.
Я уже писал гостевую на файлах и на БД и заметил, что с БД во много раз удобней и приятней работать.
Спустя 8 минут, 17 секунд (26.09.2009 - 14:43) Гость_hara написал(а):
вот прочитай http://habrahabr.ru/blogs/i_am_insane/70140/
Спустя 2 минуты, 46 секунд (26.09.2009 - 14:46) FatCat написал(а):
| Цитата (sergeiss @ 26.09.2009 - 15:04) |
| в итоге получит то, о чем писал Nikitian. |
Неоднозначно.
Несомненно, БД оптимальны для поиска информации. С одим "но": информации на английском языке.
На любом другом языке полнотекстовые индексы ищут только точные вхождения целых слов, да и те сикось накось.
Если бы я сейчас начал с нуля писать форум, я бы писал его в основном на файлах со вспомогательными таблицами в БД.
И писал бы его сразу с дублированием. Например, при отправке сообщения, оно писалось бы новым файлом сообщения и дописывалось бы в единый файл всех сообщений форума. Первый для отображения, второй для поиска.
В таблицах же только каркас: для сообщения родительский элемент топик; для топика родительский элемент форрум; и т.д.
Спустя 1 час, 55 минут, 56 секунд (26.09.2009 - 16:42) WhiteKnight написал(а):
Вот еще узнал про SQLite она вроде как на текстовых файлах работает. (вернее одном)
Это же вроде у нее через ООП резализованно ?
А по производительности она лучше или хуже MySQL ?
Это же вроде у нее через ООП резализованно ?
А по производительности она лучше или хуже MySQL ?
Спустя 2 часа, 15 минут, 51 секунда (26.09.2009 - 18:58) PandoraBox2007 написал(а):
без Бд твой форум много не выдержит файловые блокировки..всетаки
нехватка IO операций тебе сайт положит
да и жесткому диску долго не жить
нехватка IO операций тебе сайт положит
да и жесткому диску долго не жить
Спустя 13 минут, 46 секунд (26.09.2009 - 19:11) sergeiss написал(а):
SQLite не "на текстовых файлах работает" Ни в коем случае!!! Да, там всё в одном файле. Но это - далеко не текстовый файл.
Как я понимаю, SQLite имеет меньше возможностей выборки данных, по сравнению с MySQL или PostgreSQL. Но если много возможностей не нужно, но тогда SQLite будет вполне хорошей альтернативой.
Там еще что хорошо - достаточно просто скопировать файл БД с одного сервера на другой (даже если с юникса на винду или наоборот), и можно спокойно работать с данными. В других БД это невозможно в принципе.
Еще плюс - хостеры не считают эту БД в списке разрешенных БД, т.е. нету ограничений на количество. Поэтому если уж SQLite есть, то можно делать много БД SQLite.
Ни в коем случае!!! Да, там всё в одном файле. Но это - далеко не текстовый файл. Как я понимаю, SQLite имеет меньше возможностей выборки данных, по сравнению с MySQL или PostgreSQL. Но если много возможностей не нужно, но тогда SQLite будет вполне хорошей альтернативой.
Там еще что хорошо - достаточно просто скопировать файл БД с одного сервера на другой (даже если с юникса на винду или наоборот), и можно спокойно работать с данными. В других БД это невозможно в принципе.
Еще плюс - хостеры не считают эту БД в списке разрешенных БД, т.е. нету ограничений на количество. Поэтому если уж SQLite есть, то можно делать много БД SQLite.
Спустя 58 минут, 6 секунд (26.09.2009 - 20:10) PandoraBox2007 написал(а):
| Цитата (sergeiss @ 26.09.2009 - 18:11) |
| SQLite не "на текстовых файлах работает" Ни в коем случае!!! Да, там всё в одном файле. Но это - далеко не текстовый файл. Как я понимаю, SQLite имеет меньше возможностей выборки данных, по сравнению с MySQL или PostgreSQL. Но если много возможностей не нужно, но тогда SQLite будет вполне хорошей альтернативой. Там еще что хорошо - достаточно просто скопировать файл БД с одного сервера на другой (даже если с юникса на винду или наоборот), и можно спокойно работать с данными. В других БД это невозможно в принципе. Еще плюс - хостеры не считают эту БД в списке разрешенных БД, т.е. нету ограничений на количество. Поэтому если уж SQLite есть, то можно делать много БД SQLite. |
Так как он открывает файл для чтения строк он отнимает больше времени если база большая (нужно каждую таблицу в отдельный SQLite). Ну и файловые операции: блокировка, чтение, закрытие файлов это занимает время. При атаке на сервер или большой посещаемости нагрузки критичная точка IO растет. Это критично особенно для посещаемых блогов
Каждый раз для чтения записи он сканирует весь файл хотя есть и индексы все равно больше времени занимает во время открытия (не хранится постоянно в памяти)
Спустя 5 минут, 40 секунд (26.09.2009 - 20:15) glock18 написал(а):
| Цитата |
| Там еще что хорошо - достаточно просто скопировать файл БД с одного сервера на другой (даже если с юникса на винду или наоборот), и можно спокойно работать с данными. В других БД это невозможно в принципе. |
это кстати не совсем так
в mysql таблицы myisam можно просто скопировать 
Спустя 18 минут, 30 секунд (26.09.2009 - 20:34) PandoraBox2007 написал(а):
| Цитата (FatCat @ 26.09.2009 - 11:49) |
| Сообщения свыше 4 000 знаков хранятся в файлах, короткие сообщения хранятся в БД. |
это пока хорошо когда нагрузочка действительно вырастет или пользователей бдует по 500 онлайн будет адски лагать в линуксе есть понятие (IO Limit файлов), хард диск не железный логично хранить в памяти
Спустя 17 минут, 4 секунды (26.09.2009 - 20:51) Nikitian написал(а):
| Цитата (FatCat @ 26.09.2009 - 11:46) |
| БД оптимальны для поиска информации. С одим "но": информации на английском языке. На любом другом языке полнотекстовые индексы ищут только точные вхождения целых слов, да и те сикось накось. |
"Вы просто не умеете их готовить."
Испугалсо ваших слов! Только что для эксперимента сделал выборку примерно такого вида
| SQL |
| select * from test where text like "%русс%" |
И оно, о чудо, нашло строку:
| Код |
| Некоторый текст на русском языке |
Т.е. ищутся всё-таки не только целые слова, но и их части!
Match-against действительно не ищет по частям слов, ну так он и не для этого сделан и работает совсем по-другому.
Полнотекстовый поиск - это не панацея для поиска. Более того, я вообще не рекомендую его использовать для поиска данных в больших часто используемых таблицах. Лучше делать свой индекс и делать собственный поиск по этому индексу так, как вам надо.
Match-against действительно не ищет по частям слов, ну так он и не для этого сделан и работает совсем по-другому.
Полнотекстовый поиск - это не панацея для поиска. Более того, я вообще не рекомендую его использовать для поиска данных в больших часто используемых таблицах. Лучше делать свой индекс и делать собственный поиск по этому индексу так, как вам надо.
Спустя 1 час, 13 минут, 53 секунды (26.09.2009 - 22:05) FatCat написал(а):
| Цитата (Nikitian @ 26.09.2009 - 21:51) | ||
| "Вы просто не умеете их готовить." Испугалсо ваших слов! Только что для эксперимента сделал выборку примерно такого вида
|
Я, собственно, не о ползанье по всей базе, а о поиске по индексам:
| SQL |
| SELECT * FROM ibf_posts WHERE MATCH(text) AGAINST ('русс' IN BOOLEAN MODE)) |
"Лайк" даже по 100-метровой таблице секунд 5 будет ползать, что медленнее чем stristr по файлу.
Поиск по полнотекстовому индексу для 100-метровой таблицы занимает пару десятых секунды, но вот беда: поиск по "fuck" найдет "fucked", а поиск по "русск" не найдет "русский"...
Спустя 21 минута, 40 секунд (26.09.2009 - 22:26) FatCat написал(а):
| Цитата (Nikitian @ 26.09.2009 - 21:51) |
| Лучше делать свой индекс и делать собственный поиск по этому индексу так, как вам надо. |
Увы, для больших таблиц у меня не получается спроектировать. Тот же пхпББ тому свидетельство: чуть перевалили за 50 000 сообщений в базе, начинаются затыки с поиском.
В принципе, сама формулировка задачи проста.
Есть база на 200+ К сообщений 200+ Мб текста, прирастает примерно по 500 сообщений в день и за год удвоится.
Нужен поиск по нескольким подстрокам с возможностью выбора: показывать если есть хотя бы одно совпадение, или только сообщения со всеми совпадениями. Желательно спроектировать на много лет вперед.
Реальная частота поисков довольно велика: 10 одновременных посетителей в среднем дают 2-3 поисковых запроса в минуту, нужно, чтобы держал до 500 одновременных посетителей на шареде.
Спустя 2 часа, 15 минут, 22 секунды (27.09.2009 - 00:42) PandoraBox2007 написал(а):
а как вам такой метод поиска с вытяжкой из сфинкса
Спустя 18 минут, 10 секунд (27.09.2009 - 01:00) Nikitian написал(а):
| Цитата (FatCat @ 26.09.2009 - 19:26) |
| Увы, для больших таблиц у меня не получается спроектировать. Тот же пхпББ тому свидетельство: чуть перевалили за 50 000 сообщений в базе, начинаются затыки с поиском. ... |
Пхпбб, если не ошибаюсь стеммером получает словоформу и кидает её в таблицу слов, далее в таблице соответствий делает пометку, где это слово встречается. Поиск по такому же принципу ведётся. Я делаю примерно так же, но в таблице слов храню crc32-хэш и выборку делаю по нему. Не думается мне, что выборка по числовому primary key из таблицы даже с несколькими миллионами записей будет медленной. Через меня проходил форум (там и подглядел его принципы работы, которые очень сильно совпадали с моими, к которым пришёл чуть ранее) с ~30 миллионами словоформ и что-то около 50кк соответствий (за вторую цифру не ручаюсь) этих слов топикам. Форум искал весьма шустро.
Спустя 48 минут, 48 секунд (27.09.2009 - 01:49) FatCat написал(а):
| Цитата (Nikitian @ 27.09.2009 - 02:00) |
| в таблице слов храню crc32-хэш |
Спасибо, классная идея!
Возьму на вооружение.
| Цитата (Nikitian @ 27.09.2009 - 02:00) |
| Форум искал весьма шустро. |
А добавлял сообщения?
У меня нередки ситуации, когда сообщения влетают по мегабайту. Это под 100 000 слов. Даже если 1000 уникальных - это 1000 запросов к БД для внесения в индекс? Хотя, запросы простые, может и 1000 будет не критично, надо тестировать...
Спустя 13 минут, 30 секунд (27.09.2009 - 02:02) Nikitian написал(а):
В зависимости от длины слов, запрос может быть и один: зависит от длины этих слов и параметра мускуля, отвечающего за максимальный размер запроса (сейчас не могу вспомнить его название).
Надеюсь помните про множественные вставки вида
Надеюсь помните про множественные вставки вида
| SQL |
| insert delayed table (val1,val2) values (1,2),(3,4) |
Плюсом благодаря delayed скорость вставки вас вообще не волнует