Forum Webscript.Ru
Программирование => Perl => Тема начата: от 12 Мая 2002, 02:42:55
-
Объясните, пожалуйста, начинающему, в двух словах, почему нужно применять MySQL, и нельзя обходиться базами, которые может делать Perl в виде текстового файла со строчками данных и полями произвольной длины, произвольного набора? Чем SQL лучше и насколько, и в каких случаях надо переходить к ним от обычных текстовых баз?
-
Лучше, т.к.
1. проекты с SQL более масштабируемы
2 надежнее (как никак, большая часть БД - это системы с многопользовательским доступом)
3. при больших объемах данных быстрее, причем существенно, ну а когда две, три, десять записей ;) то наоборот текстовые БД существенно быстрее.
4. легче программировать и структурировать :) особенно когда структура данных довольно сложная
-
есть дока по практическому применеию связки Perl+MySQL?
Не документация на DBI (типа такая-то функция возвращает кое-что из ничего), а что-нибудь конкретное в примерах, а именно - вставка данных, чтение, добавление колонок/строк/изменение....
-
есть отличная книжка "Программирование на Perl DBI", авторы: Аллигатор Декарт, Тим Банс. Издательство OReilly, на русском издана издательством "Символ"
Как говорится, весьма и весьма. Несколько глав посвящено альтернативным DB (текстовые, DBM), а потом о SQL +Perl
-
...при больших объемах данных быстрее, причем существенно
А какие объемы уже считаются большими?
-
Спасибо, пойду копать в гамазинах....
-
А какие объемы уже считаются большими?
;) все зависит от того, как все организовано
Т.е. стоит тесты поставить и т.д. Но где-то я видел результаты подобного теста - если в каждой строке текстовой БД несколько полей, то уже при 1000 строчках SQL выползет вперед по скорости при выполнении всех операций. Ведь при замене, обновлении, удалении для текстовой БД как правило приходится перебирать все записи (правда, если используются записи фиксированной длины, то се перебирать не придется).
+ не стоит забывать о надежности.
-
Вот, это уже хоть что-то. Вопрос, насколько вперед. Если какая-то операция делается 1 секунду, а в SQL - 0,8 с или даже 0,5 c, то так ли это существенно? И как в реальной жизни применять записи фиксированной длины, например, для форума? На каком уровне их зафиксировать. И, опять же, зачем это нужно? В чем, и насколько, выигрыш?
А насчет надежности - если не забывать запирать файлы flock - то почему надежность ниже? Моя первая Доска объявлений уже два года работает автономно - и тьфу-тьфу.
-
насчет надежности - если не забывать запирать файлы flock - то почему надежность ниже?
;) в том то и дело, что если его запереть, а операция довольно продолжительная, то остальные ждут. В то время как SQL БД поддерживает одновременно несколько коннектов и при этом гарантирует надежность и достоверность данных.
В форуме это критично.
и flock - это еще не значит что никто к этому файлу не обратится пока он используется другими.
Чем больше пользователей, тем больше опасность того, что все накроется.
И как в реальной жизни применять записи фиксированной длины, например, для форума?
;) ф-ции pack, unpack, sbstr
у них есть большой недостаток: если размер данных меньше поля определенной длины, то данные все равно доращиваются до нужных размеров поля путем вставки заполнителей, т.е. размер файлов получается весьма немаленький из-за такой неэффективной записи;
если вдруг что-то недодумаете или произойдет сбой во время записи и допустим запишется не все, то ;) потом найти что либо сам скрипт не сможет.
+ Довольно "жесткая" логика у текстовых БД и у скрипты как правило обладают плохой масштабируемостью (хотя тут много от программиста зависит)
-
>flock - это еще не значит что никто к этому файлу не обратится пока он используется другими
А что же это значит?
Я делаю так:
open(A,"<$basa") || die print " $!";
flock(A,2);
@users=;
flock(A,8);
close (A);
т.е. закрываю сразу, а работаю с @users, а файл уже свободен.
Так же и при записи. Если что и потеряю, так не в базе, а только с оперативными данными, что не так страшно.
>а операция довольно продолжительная,
или сам процесс запирания продолжительный? Сколько и почему? И как обходится Windows без этого запирания?
А вообще кое-что проясняется. Жалко только, что цифр мало. А мне, как инженеру, правда по другой специальности, слова долго, надежнее, быстрее мало о чем говорят, скорее на эмоции походит. Нужно в цифрах оценить насколько, и сколько потом это улучшение будет стоить, и только тогда можно о чем-то судить, да и то для данного конкретного случая. И может эффективнее решить проблему скорости со стороны харда - уж очень быстро все дешевеет.
>Довольно "жесткая" логика у текстовых БД
А конкретнее, это интересно.
-
>flock - это еще не значит что никто к этому файлу не обратится пока он используется другими
А что же это значит?
;) а то, что flock ничего физически не запирает - это как договоренность, мол я работаю не лезьте. Если к "закрытому" файлу обратится кто-то не использующий функцию flock при открытии, то он доступ к нему получит без проблем.
Кроме того, нельзя использовать flock пока вы не открыли файл, т.е.
1 открываем
2 потом flock
а между первой и второй - есть промежуток небольшой :) за который "возможно" сделать что-то не то. Некоторые поэтому делают иначе - открывают пустой файл-локер, его flock, а потом открывают уже рабочий файл
open(L, ">lock.lock")||die("Error:$!");
flock(L,2);
open(DB, "...
close DB;
close L;
Об этом подробно и с примерами тут:
http://www.samag.com/documents/s=4075/sam1013019385270/sam0203i.htm
>а операция довольно продолжительная,
или сам процесс запирания продолжительный? Сколько и почему? И как обходится Windows без этого запирания?
нет. Подразумевалась работа с данными.
Можно действительно все в переменную скинуть и закрыть, и когда данных немного, то это нормально. Но если БД большая, то грузить все в память - это не всегда удачное решение, иногда занимаются построчным считыванием и сразу делают то или иное действие, значит файл будет занят долго.
а Win.. ;) в 9x нету, но наверняка они там что-то свое придумали но никому не сказали. Можно переименовывать lock файл и проверять переименован он или нет (т.е. альтернатива - флок поставлен или нет)
Нужно в цифрах оценить насколько, и сколько потом это улучшение будет стоить, и только тогда можно о чем-то судить, да и то для данного конкретного случая. И может эффективнее решить проблему скорости со стороны харда - уж очень быстро все дешевеет.
в цифрах то можно Benchmark.pm ;) все-таки все зависит от того, что нужно. А то что все дешевеет - так это можно и иначе смотреть, например раньше MySQL предлагали существенно меньше хостеров в тарифных планах чем сейчас, а сейчас почти что обязательно суют по умолчаниюДовольно "жесткая" логика у текстовых БД
А конкретнее, это интересно.
все критично зависит от того, насколько сразу все спланируется. Это конечно относится ко всем БД, но с SQL базами можно выкрутится за счет гибкости самого языка SQL, а вот в случае с текстом - все думаете вы, все выборки алгоритмы записи, обновление, разбивку полей делаете тоже вы.. и если вдруг понадобится ввести новое поле, или нужно будет добавить сортировку по какому-то полю то могут возникнуть сложности со встраиванием этих "дополнительных" возможностей в скрипт.
А есть же и альтернативы:
DBM (DB_File.pm, BerkeleyDB.pm) кстати их можно и в текстовые файлы кидать, если задать тип ДБ RECNO (правда у DBM с блокировкой не лучше дело обстоит, чем у текстовых БД)
(у других DBM администраторов ограничения на размер записи 1-5кб)
Можно на текстовых БД сделать и SQL базу DBI+DBD::CSV (громоздко правда)
-
>Но если БД большая, то грузить все в память - это не всегда удачное решение
1 млн. записей по 100 байт в строке = 100 кБ - это много для сбрасывания в память?
1000 записей по 1кБ = 1мБ - это много или мало для памяти? Интересно, что по этому поводу думают провайдеры.
А насчет вдруг понадобившегося еще одного поля - это я на себе испытал. Неприятно, но жить можно.
Ха-ха!
Пошел по Вашей ссылке http://www.samag.com/documents/s=4075/sam1013019385270/sam0203i.htm
а там:
Service Unavailable
We\'re sorry, but our server is currently experiencing technical difficulties. We appreciate your patience; we\'ll have things working again as soon as possible.
Internal error: Can\'t connect to database: java.sql.SQLException: JZ006: Caught IOException: java.net.ConnectException: Connection refused
Вот Вам и надежность java.sql.SQL
Кстати я не первый раз встречаю ошибки из-за SQL.
Я так думаю, что если хостер достаточно квалифицированный, то у него и Перл надежно будет пахать. Причем без всяких заездов, типа "все скрипты только в эту папку, а HTML - в эту". Прямо все бросай, и меняй структуру сайта под этого хостера. На что они рассчитывают? На Virtualave.net клади куда хошь, пиши что хошь - за два года ни одного сбоя! Даже когда хозяин сменялся. И это бесплатно! А ведь у них 1,5 млн. сайтов...
Вот чем больше определяется надежность. Надежность - понятие интегральное.
-
Кстати я не первый раз встречаю ошибки из-за SQL
в случае текстовой БД это бы означало полный капут всем данным :)
такой сайт уже на тексте не сделаешь.
1 млн. записей по 100 байт в строке = 100 кБ - это много для сбрасывания в память?
1000 записей по 1кБ = 1мБ - это много или мало для памяти? Интересно, что по этому поводу думают провайдеры.
;) я думаю, скрипт даже не выполнится ;)) попробуйте в домашних условиях запустить. А вот с SQL кол-во записей как бы по барабану (в смысле нагрузки сервера. хотя есть некие "рекомендуемые" объемы для простых SQL баз)Причем без всяких заездов, типа "все скрипты только в эту папку, а HTML - в эту".
спорное утверждение, все таки это стиль Unix - все по разным директориям, вместе ничего не замешиваем.
-
>с SQL кол-во записей как бы по барабану
Получается, что в SQL идет не построчное сканирование полей, а как-то по-другому? Можно подробнее об этом? Как это все физически происходит, в чем отличие от текста? Можно ведь и текст записать двоичным, или я опять что-то не понимаю?
>я думаю, скрипт даже не выполнится
Неужели 1Мб для памяти много? Или у Перла есть какие-то теоретические ограничения?
-
>>Неужели 1Мб для памяти много? Или у Перла есть какие-то теоретические ограничения?
У Перла ограничений нет. И 1 Мб это не много. Ограничения обычно есть на сервере, потому что кто-нибудь вот так же подсчитает "1 млн. записей по 100 байт в строке = 100 кБ" и решит, что 100 кб это ерунда, можно скрипт запускать. А Перлу потом мучиться придется, потому как "1 млн. записей по 100 байт в строке" это 100 МБ одних только данных, плюс накладные расходы на создание массива, которые у Перла достаточно велики, и в данном случае могут вылиться в еще 50 Мб.
-
Получается, что в SQL идет не построчное сканирование полей, а как-то по-другому?
там используется своя система представления данных и это отдельная ;) ну если не наука, то отдельное и весьма специфичное направление.
Ну а кроме того, это БД реализуется обычно на C/C++, т.е. иные скорости работы.
-
Не понял, как это
..."1 млн. записей по 100 байт в строке" это 100 МБ одних только данных,... ? 100кБ! Что за "данные"?
-
Кто-то из нас двоих в школе плохо учил арифметику, и я даже знаю кто...
1000000*100=100000000
Ну никак у меня не получается 100 кб.
-
Прошу пардону! Лажанулся... Ошибся на каких-то 3 порядка Ж-)
Но все-таки, какие объемы памяти для хостер-провайдеров критичны - надо же знать границы дозволенного. И как в случае с БД, разве не грузится весь большой файл в память, когда что-то ищется, или там как-то по-другому?
Еще раз извиняюсь за ляп.
-
Спасибо за ссылку по flock - ценный ресурс. В летнем выпуске как раз будет о запоре семафором в не-Unix, интересно...
-
А вот интересно, на чем этот форум сделан, на каких базах?
-
А как же индексы ????? Без них в 1 млн записей будет намного медленнее!!!
-
А как же индексы ?????
- в каком смысле?
-
По теме. К слову о надежности SQL.
Вчера захожу на один сайт php-шный - и вижу кучу строчек одинаковых - мол, количество одновременных запросов MySQL выше допустимого - и все это вперемешку с поехавшим дизайном. Вот приятно пользователям это лицезреть! А на текстовой базе с Перлом просто пришлось бы чуть подождать, может быть, или уж просто показать белый экран - все лучше чем поломанный дизайн. А если этот сайт - представительство коммерческой фирмы? - какая дискредитация!
Вот Вам и надежность SQL, "многопользовательская природа". Есть теория, а есть практика. Если бы показывался просто белый экран, ну посетитель обвинял бы может, провайдера за плохую связь, или еще как-то, а то ведь с фирмы смеяться будут!
-
Получается, что в SQL идет не построчное сканирование полей, а как-то по-другому
Используется индексирование.
-
Вчера захожу на один сайт php-шный - и вижу кучу строчек одинаковых - мол, количество одновременных запросов MySQL выше допустимого - и все это вперемешку с поехавшим дизайном. Вот приятно пользователям это лицезреть!
Это уже не вопрос работы с SQL, а вопрос стиля программирования. Всегда есть возможность перехватить сообщение об ошибке и обработать.
Не говоря уже о том, что ошибки при чтении файла совершенно также будут выплевываться на экран - это все из области распределения системных ресурсов.
Бывает теория, а бывает практика...
-
:
А вот интересно, на чем этот форум сделан, на каких базах?
PHP + MySQL
-
ну и зачем ты эту тему вытащил наверх?
тема закрыта