Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | | | |
А, я так понял, ты вообще фантазировать любишь..... 11.07.04 21:52 Число просмотров: 1549
Автор: ne_budu_pozority_tut_nik Статус: Незарегистрированный пользователь
|
> ещё и параноик. Было дело, когда я CGI'шки на ASM'е писал..
А, я так понял, ты вообще фантазировать любишь... Расскажи-ка лучше как это выглядело..
|
|
<web building>
|
текстовики vs базы в качестве хранилища 01.07.04 16:21 [!mm, amirul, Den]
Автор: !? <!?> Статус: Member
|
Может ли кто-нибудь аргументированно указать плюсы/минусы использования текстовиков/баз данных в качестве хранилища?
Мне часто предъявляют, что я лох, тк использую текстовики, а не базы, но я ещё так не испытал особой нужды в переходе на вторые.
Да и вообще, используя текстовики, я знаю что, где и как устроено, и уверен что не допущу ошибку, которая повлечёт за собой серьёзные последствия..
|
|
может хватит флейма? тема уже исчерпала себя, имх 13.07.04 11:17
Автор: !mm <Ivan Ch.> Статус: Elderman
|
|
|
|
Значит таких нужд не было.. База данных - это высоконадежный... 08.07.04 22:27
Автор: ne_budu_pozority_tut_nik Статус: Незарегистрированный пользователь
|
> Может ли кто-нибудь аргументированно указать плюсы/минусы
> использования текстовиков/баз данных в качестве хранилища?
>
> Мне часто предъявляют, что я лох, тк использую текстовики,
> а не базы, но я ещё так не испытал особой нужды в переходе
> на вторые.
> Да и вообще, используя текстовики, я знаю что, где и как
> устроено, и уверен что не допущу ошибку, которая повлечёт
> за собой серьёзные последствия..
Значит таких нужд не было.. База данных - это высоконадежный продукт, обладающий высокой продуктивностью и выполняющий сложные математические и логические задачи.
Я программирую на PHP, как-то хотел написать игру. Но перед этим я перечитал документацию mySQL-А, И случайно увидел почти математические и символьные функции, которыми я пользуюсь в программироваии..
Базы данных в интернете кроме надежности могут давать еще и безопасность. При умелом использованиии можно значительно понизить риск взламываемости сайтов... Но сегодня навряд-ли найлуца люди, когторые выставляют для отдельных таблиц - различные права доступа...
Может это и правельно.. Безопасность настолько высокая не нужна... Не Пентагон мы все-таки...
|
| |
Для частных случаев написание своей собственный базы... 09.07.04 00:39
Автор: Heller <Heller> Статус: Elderman
|
> Значит таких нужд не было.. База данных - это
> высоконадежный продукт, обладающий высокой продуктивностью
> и выполняющий сложные математические и логические задачи.
Для частных случаев написание своей собственный базы построенной на файлах даже более эффективно в плане производительности. то уже обсуждалось, почитай топик.
> Я программирую на PHP, как-то хотел написать игру. Но перед
> этим я перечитал документацию mySQL-А, И случайно увидел
> почти математические и символьные функции, которыми я
> пользуюсь в программироваии..
И чего? =)
> Базы данных в интернете кроме надежности могут давать еще и
> безопасность. При умелом использованиии можно значительно
> понизить риск взламываемости сайтов... Но сегодня
> навряд-ли найлуца люди, когторые выставляют для отдельных
> таблиц - различные права доступа...
Не понятно.. По-подобрей пожалйста про этот пункт.. не догоняю..
> Может это и правельно.. Безопасность настолько высокая не
> нужна... Не Пентагон мы все-таки...
Угу.. Вот только взлом базы - первый шаг к захвату сервера. А дальше можно слать СПАМ, к примеру. И разбирайся потом с РОСНИИРОС. Не надо никогда недооценивать безопастность. Хотя бы когда в этот форум пишешь :-)
ЗЫ. А грамотно писать на русском языке, значит, не обязательно?
|
| | |
Может при работе 2-3х файлов скорость работы и быстрее.. Но... 09.07.04 19:24
Автор: ne_budu_pozority_tut_nik Статус: Незарегистрированный пользователь
|
> > Значит таких нужд не было.. База данных - это
> > высоконадежный продукт, обладающий высокой
> продуктивностью
> > и выполняющий сложные математические и логические
> задачи.
>
> Для частных случаев написание своей собственный базы
> построенной на файлах даже более эффективно в плане
> производительности. то уже обсуждалось, почитай топик.
Может при работе 2-3х файлов скорость работы и быстрее.. Но при разработке больших проектов сталкиваешься с полным хасом огромных баз данных (таблиц).
Именно для правильной связи таблиц и логически обоснованной работы с целью сохранять целостность баз данны и были разработаны SQL, ORACLE.
Можно предположить, что при неудачной записи в файл данных - файл будет поврежден, и при большом количестве данных только этот факт вызовет катастрофу. Хочу посмотреть , как такой файл будете чинить..
Есть еще такой фактор, что при огромном количестве информации mySQL, ORACLE будут работать с коэфициентом выше чем с файлами..
Вообще, что я скажу ребята... @#$ней вы страдаете....
Я как-то брал в руки огромный томик теории баз данных - это вам не цацки пеци... Это теоретически и практически обоснованная огромная работа по работе с базами денных, где скорость, безопасность и безотказность - главные принципы работы.
>
> > Я программирую на PHP, как-то хотел написать игру. Но
> перед
> > этим я перечитал документацию mySQL-А, И случайно
> увидел
> > почти математические и символьные функции, которыми я
> > пользуюсь в программироваии..
>
> И чего? =)
А того, что это не конь с яйцами и таблицами... А продукт в котором количество возможностей настолько широко, что никто из вас, включая мну не представляем...
>
>
> > Базы данных в интернете кроме надежности могут давать
> еще и
> > безопасность. При умелом использованиии можно
> значительно
> > понизить риск взламываемости сайтов... Но сегодня
> > навряд-ли найлуца люди, когторые выставляют для
> отдельных
> > таблиц - различные права доступа...
>
> Не понятно.. По-подобрей пожалйста про этот пункт.. не
> догоняю..
Не только программно можно ограничивать действия при работе с mySQL но и условиями доступов. Например "прозрачный" скрипт , который имеет доступ к БД , ломаемый сегодня имея ту или иную уязвимость - содержит ключик к БД. Имя ключик (данные доступа к серверу) видишь всю информацию..
Но скажем для таблицы кредитных кард в БД можно дать доступ только на запись... И имея только второй (непросматриваемый в скриптах) код к БД можно увидеть эти данные.
>
>
> > Может это и правельно.. Безопасность настолько высокая
> не
> > нужна... Не Пентагон мы все-таки...
>
> Угу.. Вот только взлом базы - первый шаг к захвату сервера.
> А дальше можно слать СПАМ, к примеру. И разбирайся потом с
> РОСНИИРОС. Не надо никогда недооценивать безопастность.
> Хотя бы когда в этот форум пишешь :-)
Можно и наоборот сказать. Взлом сервера - первый шаг к захвату БД ;)
А взломанных сайтов могу достать кучу.. Да толку ? Ты спаммер ?
>
> ЗЫ. А грамотно писать на русском языке, значит, не
> обязательно?
Я вроде не Пушкин...
Алексей
========
[CETb]
|
|
Небольшое уточнение 07.07.04 16:11
Автор: Heller <Heller> Статус: Elderman
|
Возможно, кого-то повторю, но вроде это ещё не упоминалось.
Если использовать в качестве базы файлы, то тогда уж не файлЫ а только ОДИН (или несколько) файлов. Ведь например в FAT32 размер кластера 32КБ - если файл отведён к примеру под топик в форуме, то это уже будут колоссальные потери. Как в других ФС будет, я не знаю, но в любом случае физический размер кластера просто обязан быть.
|
| |
А по фигу 07.07.04 16:38
Автор: amirul <Serge> Статус: The Elderman
|
> Возможно, кого-то повторю, но вроде это ещё не упоминалось.
>
> Если использовать в качестве базы файлы, то тогда уж не
> файлЫ а только ОДИН (или несколько) файлов. Ведь например в
> FAT32 размер кластера 32КБ - если файл отведён к примеру
> под топик в форуме, то это уже будут колоссальные потери.
У меня NTFS отформатирован (по умолчанию) с 8 секторов/кластер. То бишь 4096. Даже с таким форумом как bugtraq (уже почти 110 тыщ сообщений) это 450 метров. Любой современный винт выдержит это без малейших проблем. А если учесть еще и удаленные топики (один Urix чего стоил :-) ), то все вообще замечательно.
> Как в других ФС будет, я не знаю, но в любом случае
> физический размер кластера просто обязан быть.
Проблема ФС в другом. Они не рассчитаны на работу с десятками/сотнями тысяч файлов в каталоге. И даже по ключевому полю - имени - поиск при таких масштабах будет весьма небыстрым.
|
| | |
Да иногда не по фигу 07.07.04 18:42
Автор: Heller <Heller> Статус: Elderman
|
Хых.. Ну это по фигу если ты сидишь на собственном серваке. А если сервер виртуальный, где каждый мег оплачивается? У меня хостинг, например, так там вообще всего 300mb выделяют.
ЗЫ. А поиск по файловый системе, как уже рассматривали, оптимизируется. Хотя случаются и геморрои.
|
| | | |
Ну в случае с виртуальным хостингом как мне кажется дисковое место будет не самым узким местом 08.07.04 12:15
Автор: amirul <Serge> Статус: The Elderman
|
> Хых.. Ну это по фигу если ты сидишь на собственном серваке.
> А если сервер виртуальный, где каждый мег оплачивается? У
> меня хостинг, например, так там вообще всего 300mb
> выделяют.
Производительность базы будет в любом случае выше. А ведь на виртуальных хостингах борятся чуть ли не за миллисекунды.
> ЗЫ. А поиск по файловый системе, как уже рассматривали,
> оптимизируется. Хотя случаются и геморрои.
Постоянная переиндексация при добавлении сообщения это ли не геморрой :-)
Хотя я не уверен, что NTFS переидексирует каталог полностью (а не добавляет новинки в индекс), но мне все еще не дают покоя рекомендации по УВЕЛИЧЕНИЮ производительности путем отключения индексирования. Если есть такие рекомендации, значит с индексированием у NTFS что то не так.
|
| | | | |
Чаще всего это выражается в запрещении установки чатов и... 09.07.04 17:09
Автор: Heller <Heller> Статус: Elderman
|
> Производительность базы будет в любом случае выше. А ведь
> на виртуальных хостингах борятся чуть ли не за
> миллисекунды.
Чаще всего это выражается в запрещении установки чатов и баннерных ротаторов - на то как именно ты что реализуешь мало кто смотрит.
> Постоянная переиндексация при добавлении сообщения это ли
> не геморрой :-)
Тут в голову возможное решение заглянуло :-) Можно разбивать всю файловую базу на несколько каталогов в каждом из которых будет лежать небольшая часть файлов. Тогда регулярную переиндексацию можно и пережить - не такие будут потери. Можно вообще организовать два каталога - один со старыми постами (в случае форума), а другой с новыми - при накоплении в последнем достаточного количества файлов перекидывать их в каталог со старыми данными и переиндексировать соответственно. Имхо, вполне эффективное решение.
|
| | | | | |
Ага 09.07.04 17:57
Автор: amirul <Serge> Статус: The Elderman
|
> Чаще всего это выражается в запрещении установки чатов и
> баннерных ротаторов - на то как именно ты что реализуешь
> мало кто смотрит.
Вот только, если ты превысишь квоту - писать тебе потом в саппорт хостера с вопросами о том, за что вырубили сайт.
> переиндексировать соответственно. Имхо, вполне эффективное
> решение.
Ага. "А нельзя сразу БАЦ?" (с) Мартышка
Вы действительно считаете, что такая система ПРОЩЕ, чем БД?
|
| | | | | | |
Да не.. Наверное я не так выразился.. Я имел ввиду не... 09.07.04 18:28
Автор: Heller <Heller> Статус: Elderman
|
> Вот только, если ты превысишь квоту - писать тебе потом в
> саппорт хостера с вопросами о том, за что вырубили сайт.
Да не.. Наверное я не так выразился.. Я имел ввиду не реализацию чатов и ротаторов, а именно реализацию баз. В общем не понятен ответ.
> Вы действительно считаете, что такая система ПРОЩЕ, чем БД?
Может быть и не проще, но гораздо понятнее. К тому же указанный способ я приводил для того только случая, когда есть неоходимость в переиндексации и её нельзя отключить. В общем случае применение приведённого метода не требуется (на практике я думаю сделать разбивку на каталоги - максимум строчек десять кода - ничего сложного и хитрого в алгоритме нет имхо)
|
| | | | | | | |
Если виртуальная машина превышает квоты на ресурсы, то ее... 12.07.04 13:16
Автор: amirul <Serge> Статус: The Elderman
|
> > Вот только, если ты превысишь квоту - писать тебе
> потом в
> > саппорт хостера с вопросами о том, за что вырубили
> сайт.
>
> Да не.. Наверное я не так выразился.. Я имел ввиду не
> реализацию чатов и ротаторов, а именно реализацию баз. В
> общем не понятен ответ.
Если виртуальная машина превышает квоты на ресурсы, то ее просто вырубают. И никаких запретов на чаты. Делай сколько хочешь чатов, но следить за производительностью - твоя задача, а не хостера.
> (на практике я думаю сделать разбивку на каталоги -
> максимум строчек десять кода - ничего сложного и хитрого в
> алгоритме нет имхо)
А в БД одна - вызов SQL-запроса. Для получения любых данных из базы - тоже одна. Я ж говорю, что БД имеют очень хорошие и простые интерфейсы. Не сложнее, чем интерфейсы работы с реестром или файлами.
|
| | | | | | | | |
На самом деле у БД свои приколы есть. 12.07.04 13:46
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
> > (на практике я думаю сделать разбивку на каталоги -
> > максимум строчек десять кода - ничего сложного и
> хитрого в
> > алгоритме нет имхо)
> А в БД одна - вызов SQL-запроса. Для получения любых данных
> из базы - тоже одна. Я ж говорю, что БД имеют очень хорошие
> и простые интерфейсы. Не сложнее, чем интерфейсы работы с
> реестром или файлами.
Все так, вот только для мало-мальски надежной работы это добро надо констрейнтами окружать по полной программе. Причем в том, что ты правильно задал все констрейнты, ты тоже не можешь быть уверен. В отличие от файловой системы, в которой многие ограничения (хорошие) зашиты в архитектуру.
Хотя in the end БД по масштабируемости, естественно, лучше. Большинство реализаций БД на основе файловых систем (какие видел) характерно непоправимой наколеночностью.
В общем, главное правило, как и везде - знать инструмент. И как я где-то здесь уже недавно написал - если софт плохо спроектирован, его не спасут никакие средства реализации.
|
| | | | |
В NTFS нельзя выключить индексирование поиска файлов по имени... Можно отключить службу индексирования, которая индексирует контент, и FS ей по барабану. Ещё можно отключить обновление времени последнего доступа к файлам. Всё! 08.07.04 13:28
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 08.07.04 13:35 Количество правок: 1
|
|
|
| | |
Не фиг индексирование файлов отключать :-P 07.07.04 17:18
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
> Проблема ФС в другом. Они не рассчитаны на работу с
> десятками/сотнями тысяч файлов в каталоге. И даже по
> ключевому полю - имени - поиск при таких масштабах будет
> весьма небыстрым.
Рассчитаны они замечательно на такие объемы :) Сабж.
|
| | | |
А я не отключаю :-) 07.07.04 17:34
Автор: amirul <Serge> Статус: The Elderman
|
> Рассчитаны они замечательно на такие объемы :) Сабж.
Кстати, тебе не кажется странным совет отключать индексирование для ПОВЫШЕНИЯ быстродействия (во всех faq-ах и твикерах именно такое назначение отключения индексирования). Какое то индексирование странное там :-)
Если случайно залезть в этот каталог эксплорером можно очень долго ждать, потому как он обновляет время доступа к каждому файлу или что-то в этом роде.
В общем сильно сомневаюсь, что НТФС масштабируется настолько.
|
| | | | |
"Капу надо крутить, капу" 07.07.04 17:43
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
> > Рассчитаны они замечательно на такие объемы :) Сабж.
> Кстати, тебе не кажется странным совет отключать
> индексирование для ПОВЫШЕНИЯ быстродействия (во всех faq-ах
> и твикерах именно такое назначение отключения
> индексирования). Какое то индексирование странное там :-)
Индексирование там вполне себе нормальное. По крайней мере поиск по 30 Гб файлов у меня работает удивительно быстро.
А отключать индексирование надо тогда, когда ты часто обновляешь данные на диске. Тогда, как и в любой БД, индексы приходится перестраивать... В частности поэтому у меня музыка и хомяки на доживающей свой век винде выброшены на отдельные разделы, на которых индексирование включено, а раздел, на котором стоит система, не индексируется.
> Если случайно залезть в этот каталог эксплорером можно
> очень долго ждать, потому как он обновляет время доступа к
> каждому файлу или что-то в этом роде.
Есть такая фигня, но обновление времени доступа можно легко отключить, даром что им почти никто не пользуется.
> В общем сильно сомневаюсь, что НТФС масштабируется
> настолько.
Масштабируется, при наличии умелых рук, желательно прямо из MS. Должна же техподдержка свой хлеб отрабатывать.
|
| | | | | |
Ну дык форум это ли не частое обновление? 07.07.04 18:01
Автор: amirul <Serge> Статус: The Elderman
|
|
|
| | | | | | |
Прошу прощения за темноту, на NTFS содержимое файлов тоже индексируется? ;) 07.07.04 18:39
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
