Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8   вперед  Ctrl      все
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Pure.....
Вот слово "успешно" я бы убрал ...


Есть опыт переноса систем с оракла и постгреса на эскулайт, архитектура при этом меняется, но функциональность остается идентичной. Так что с точки зрения конечного пользователя разницы нет. С точки зрения разработчика - чем проще СУБД, тем сложнее разработка, зато и проще администрирование (эскулайт администрирования вообще не требует, хотя временами нужно дописать требуемые в проекте модули, но при установке на нескольких хостах лучше уж один раз дописать, чем годами администрировать). Так что вполне себе успешно.
12 апр 10, 11:48    [8614529]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
SERG1257
Member

Откуда:
Сообщений: 2934
MBG
С точки зрения разработчика - чем проще СУБД, тем сложнее разработка
Согласен. Просто изобретаем велосипед
MBG
зато и проще администрирование
С какой стати? Административные задачи сами собой испарились? Пользователи сами собой завелись с нужными правами, ресурсы (память/диск) сами собой эффективно распределились в зависимости от нагрузки?
MBG
скулайт администрирования вообще не требует
Это просто значит, что для данной задачи дефолтные настройки являются оптимальными.
MBG
хотя временами нужно дописать требуемые в проекте модули, но при установке на нескольких хостах лучше уж один раз дописать, чем годами администрировать
Согласен, только вероятность бага в вашем велосипеде куда выше, чем в фиче взрослой СУБД по причине лучшего тестирования последней
12 апр 10, 19:57    [8618391]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Saller
Member

Откуда: exUSSR
Сообщений: 1141
SERG1257
MBG
зато и проще администрирование
С какой стати? Административные задачи сами собой испарились? Пользователи сами собой завелись с нужными правами, ресурсы (память/диск) сами собой эффективно распределились в зависимости от нагрузки?

Судя по Вашему высказыванию все эти функции сами делаются в продвинутой СУБД, а в простой все надо делать руками админа?
13 апр 10, 00:45    [8618909]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
SERG1257

С какой стати? Административные задачи сами собой испарились? Пользователи сами собой завелись с нужными правами, ресурсы (память/диск) сами собой эффективно распределились в зависимости от нагрузки?


Как пример - файловые СУБД работают с правами ФС, и правильно, ибо незачем права и роли дублировать на уровне самой СУБД. При желании можно и ACL для ФС включить, если что-то хитрое нужно. С памятью и диском тоже все легче, т.к. нет гигантских пулов shared memory - пережитков мэйнфреймов.

SERG1257
Это просто значит, что для данной задачи дефолтные настройки являются оптимальными.


Что есть в вашем понимании "дефолтовые настройки"? Апстримовская сборка, сборка из моего репозитория, выставляемые приложением параметры? :-) Я говорил про то, что не требуется постоянно настраивать при изменении нагрузки/соотношения типов запросов/объема данных в БД/etc. Пример - при изменении названных величин в постгресе съезжают все планы запросов, что требует периодической перенастройки. Да еще чертов гистерезис при изменении значений параметров.

SERG1257
Согласен, только вероятность бага в вашем велосипеде куда выше, чем в фиче взрослой СУБД по причине лучшего тестирования последней


Странное утверждение. Есть понятие полноты тестового покрытия, а "лучшее тестирование" - это вы что, верите в исчерпывающее тестирование методом тыка (вручную)? Например, тест модуля работы с ip-адресами:
http://sqlite.mobigroup.ru/artifact/b0c8fcc099
Вы готовы на основе своих знаний о "взрослых СУБД" предложить свой комплект тестов?..
13 апр 10, 00:50    [8618911]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Saller
SERG1257
...

Судя по Вашему высказыванию все эти функции сами делаются в продвинутой СУБД, а в простой все надо делать руками админа?


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

Типичная задача - создать тестовое распределение, обучить планировщик БД на нужном наборе запросов, получить статистику, по которой строятся нужные планы запросов. Как теперь результат обучения тестовой БД перенести на рабочую? В эскулайте просто - сохранить статистику из тестовой и залить в рабочую. А в постгресе, мускуле, и многих других ответ один - никак, им нужен админ, постоянно занимающийся отслеживанием поведения БД и подстройкой. Вот это и входит в стоимость администрирования. Добавлю, что и распределением памяти, дискового IO и проч. намного эффективнее занимается ОС, нежели самые навороченные СУБД. И уж вовсе ни к чему дублировать названные функции в СУБД.
13 апр 10, 00:59    [8618917]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Vinny the POOH
Member

Откуда: Киев
Сообщений: 1525
MBG,


Как пример - файловые СУБД работают с правами ФС, и правильно, ибо незачем права и роли дублировать на уровне самой СУБД.


А row-level security, например, как делать? Для трёхзвенной архитектуры, конечно, не столь важно, но всё же?

автор

С памятью и диском тоже все легче, т.к. нет гигантских пулов shared memory - пережитков мэйнфреймов.


А куда прикажете кешировать планы запросов, статистику и частоиспользуемые блоки данных? Всецело полагаться на кеш ОС? Он не оптимизирован для этого, нет...

Конечно, для запросов вида SELECT * FROM моя_телефонная_книжка SQLite, атсос или фокспро - вне конкуренции, но для чего-то сложнее - нет. Иначе не было бы "навороченных" СУБД...
13 апр 10, 01:00    [8618918]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
SERG1257
Member

Откуда:
Сообщений: 2934
Saller
Судя по Вашему высказыванию все эти функции сами делаются в продвинутой СУБД, а в простой все надо делать руками админа?
Это был ответ на скулайт администрирования вообще не требует
MBG
Я говорил про то, что не требуется постоянно настраивать при изменении нагрузки/соотношения типов запросов/объема данных в БД/etc
То есть у вас one size fits all. Один размер на всех. При этом с необходимостью настройки вы согласны.
MBG
Пример - при изменении названных величин в постгресе съезжают все планы запросов, что требует периодической перенастройки
Если постгресс попытался подстроиться под изменившиеся условия и ошибся то это баг. По-вашему лучше было тупо закрутить все гайки?
MBG
Есть понятие полноты тестового покрытия, а "лучшее тестирование" - это вы что, верите в исчерпывающее тестирование методом тыка (вручную)?
Да я верю, что в вашем велосипеде нечему ломаться.
MBG
Добавлю, что и распределением памяти, дискового IO и проч. намного эффективнее занимается ОС, нежели самые навороченные СУБД.
А мужики-то не знают.
Я допускаю, что в вашем случае действительно велосипед лучше, чем автомобиль или грузовик.
Я не согласен что велосипед всегда может их заменить но функциональность остается идентичной
13 апр 10, 02:06    [8618950]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
какой полет мысли, а никто не оценил

MBG
В эскулайте просто - сохранить статистику из тестовой и залить в рабочую.

интересно в чем смысл в переносе учитываю нишу и объемы типичной бд sqllite ?
если речь о системной статистики то сгенерить ее от балды позволит оптимизатору генерить более прямые планы. полезность системной статистики собранной с тестового PIII 500Mhz с IDE дисками на 3GHZ xeon с SCSI даже не нулевая, а отрицательная. с исходными от PIII у оптимизатора точно не будет шансов сгенерить хотя бы близкий к оптимальному план.
если речь о статистики таблиц, индексов - то в любой взрослой субд эта статистика собирается автоматом и без вмешательство дба. кстате, в отличие от sqllite взрослая субд имеет сотню механизмов по отслеживанию устаревшей статистики, не говоря уже о отслеживании не оптимальных планов и огромный пласт наворотов вокруг.
тайный смысл в переносе 3 байтов "статистики" для типичной sqllite базы в 3Мб думаю для меня останется загадкой.

MBG
Добавлю, что и распределением памяти, дискового IO и проч. намного эффективнее занимается ОС, нежели самые навороченные СУБД. И уж вовсе ни к чему дублировать названные функции в СУБД.

глубокая мысль, но к сожалению поражает не глубиной. если оптимизатор лишен знания того, что у него в кеше он тупо не может принять решение какой метод доступа применить к таблице/индексу. план запроса будет отличаться если оптимизатору известно, что в кеше менее 1% нужного индекса от того который будет при знании о том что 99% индекса уже в кеше. я не говорю уже о том, что взрослая субд управляет и дает пользователю управлять объектами в кеше. оракл, например, мелкие таблицы кеширует целиком и не позволяет им выпасть из кеша.
к стате, огромная проблема куцых субд с небогатым набором методов доступа - вымывание кеша. запрос в sqllite читающий большую таблицу тупо забьет кеш оси одной таблицей со всеми вытекающими...

MBG
Как пример - файловые СУБД работают с правами ФС, и правильно, ибо незачем права и роли дублировать на уровне самой СУБД.

в том то и дело, там где у взрослой без единого телодвижения дается из коробки в ФС приходится изобретать дорогие велосипеды: не дать пользователю просто скопировать файлы БД или записать мусор hex-редактором. до сих пор помню месяцами бегающих фокспро-гайз по этажам прочесывающих сотни компов и разыскивающих, что за гады ежедневно приносят вирус дописывающий свое тело без разбора во все сетевые файлы, в том числе dbf
13 апр 10, 03:11    [8618998]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
Yo.!
какой полет мысли, а никто не оценил

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

Там у него какие-то катастрофические проблемы для всех СУБД, стоит лишь объёму данных превысить объём ОЗУ. Причём проблемы жуть как неразрешимы.
Здесь у него, видишь ли, любая современная СУБД успешно работает с десятками гигабайт. Причём даже СУБД не нужна.
Там у него с кешированием данных, индексов, распределением памяти, управлением IO и прочей лабудой такие огроменные сложности, что никакие (даже специально для этого созданные) средства БД при поддержке квадратнолобых теоретиков с этим справиться не в состоянии.
Здесь у него те же самые задачи - фи, раз плюнуть, оказывается с этим справляется даже операционная система, не знающая ровным счётом ничего про то, с чем же именно она работает.

Просто диву даёшься, как можно за столь короткое время высказать два диаметрально противоположных суждения, и - апплодисменты - оба раза сказать несусветнейшую чушь

Я не доктор, но товарисчу MGB пора лечиться.
Если это вообще лечится.
13 апр 10, 04:33    [8619022]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
ЛП

Там у него какие-то катастрофические проблемы для всех СУБД, стоит лишь объёму данных превысить объём ОЗУ. Причём проблемы жуть как неразрешимы.
Здесь у него, видишь ли, любая современная СУБД успешно работает с десятками гигабайт. Причём даже СУБД не нужна.
Там у него с кешированием данных, индексов, распределением памяти, управлением IO и прочей лабудой такие огроменные сложности, что никакие (даже специально для этого созданные) средства БД при поддержке квадратнолобых теоретиков с этим справиться не в состоянии.
Здесь у него те же самые задачи - фи, раз плюнуть, оказывается с этим справляется даже операционная система, не знающая ровным счётом ничего про то, с чем же именно она работает.


Если своей головой подумать не хотите, то посмотрите хотя бы, к примеру, зачем оракл использует вспомогательную СУБД (timesten). Будете утверждать, что это решение несуществующих проблем? Или решение проблем, которые запросто можно решить средствами оракл, только его разработчики о том не знают? Хинт: то, что проблема неразрешима средствами самой СУБД, отнюдь не означает неразрешимость в целом.
13 апр 10, 10:45    [8619801]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Vinny the POOH

А row-level security, например, как делать? Для трёхзвенной архитектуры, конечно, не столь важно, но всё же?


Пожалуйста:

The "authorizer" method
The "authorizer" method provides access to the sqlite3_set_authorizer C/C++ interface. The argument to authorizer is the name of a procedure that is called when SQL statements are being compiled in order to authorize certain operations. The callback procedure takes 5 arguments which describe the operation being coded. If the callback returns the text string "SQLITE_OK", then the operation is allowed. If it returns "SQLITE_IGNORE", then the operation is silently disabled. If the return is "SQLITE_DENY" then the compilation fails with an error.

If the argument is an empty string then the authorizer is disabled. If the argument is omitted, then the current authorizer is returned.


Хоть на уровне ячейки делается проверка доступа.

Vinny the POOH

А куда прикажете кешировать планы запросов, статистику и частоиспользуемые блоки данных? Всецело полагаться на кеш ОС? Он не оптимизирован для этого, нет...


Статистика хранится в системных таблицах, посмотрите тот же постгрес. Планы запросов прекрасно кэшируются на уровне клиентского подключения, глобальный кэш для них не особо полезен. Что касается часто используемых блоков данных то и вовсе - одна из проблем постгреса, в частности, это двойная буфферизация, т.к. постгрес кэширует уже закэшированнные ОС данные. И это проблема почти всех СУБД, исключая разве что оракл на raw device (нет ФС - нет кэша ОС). Так что кэш ОС есть всегда, только СУБД в своем большинстве не умеют им пользоваться. И этот кэш ничуть не хуже кэша СУБД, алгоритмы аналогичные используются (см. lru). Более того, в рэйд-контроллерах есть еще и кэш записи, притом более эффективный, нежели в СУБД и часто используемый совместно с СУБД :-) Это и без рэйд-массива легко проверить - с десктопными дисками 7200 rpm СУБД работает хуже, нежели с чем-то вроде 10 000 rpm raptor, хотя скорость линейного чтения фактически идентична и при идеальном кэшировании и планировании IO в СУБД разницы от более "умного" контроллера диска с большей глубиной очереди быть не должно.

Vinny the POOH

Конечно, для запросов вида SELECT * FROM моя_телефонная_книжка SQLite, атсос или фокспро - вне конкуренции, но для чего-то сложнее - нет. Иначе не было бы "навороченных" СУБД...


Вы пытаетесь доказать логичность и необходимость чего-то самим фактом его существования? Забавно, т.к. это догмат веры, а к логике отношения иметь не может, и обычно выражается как "что боженька пошлет". Задумайтесь хотя бы, сколько различных "навороченных" систем сгинуло за короткий век существования электронной вычислительной техники...
13 апр 10, 11:06    [8619979]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Yo.!

интересно в чем смысл в переносе учитываю нишу и объемы типичной бд sqllite ?


Припоминается мне одна система на эскулайт, состоящая из кластера 10-ти ксеонов с 32 ГБ ОЗУ каждый, на которых крутятся in-memory эскулайт БД как раз размером в эту ОЗУ. Для вашего сведения, московский биллинг сотового оператора большой тройки на оракле хранит около 16 терабайт данных и работает на очень мощном "железе". Так что вот не надо заявлять, что мол БД на треть терабайта это такая мелочь, что не заслуживает внимания. У меня пока не возникало потребностей работать с БД более нескольких десятков Гб размером, хотя тестирую проекты обычно на БД в 10 раз больших, нежели их планируемый рабочий размер. т.е. до сотен Гб.

Yo.!

полезность системной статистики собранной с тестового PIII 500Mhz с IDE дисками на 3GHZ xeon с SCSI...


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

Yo.!

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


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

Yo.!

тайный смысл в переносе 3 байтов "статистики" для типичной sqllite базы в 3Мб думаю для меня останется загадкой.


Если у вас все БД такого размера, то я вовсе не понимаю, зачем вам "навороченные" СУБД. Наверное, используете для них как минимум оракл?.. Если нужно, чтобы ехало, а не шашечки, то для БД от гигабайта до десятков гигабайт вполне хватает эскулайта (уточняю - для нескольких тысяч одновременных пользователей).

Yo.!
огромная проблема куцых субд с небогатым набором методов доступа - вымывание кеша. запрос в sqllite читающий большую таблицу тупо забьет кеш оси одной таблицей со всеми вытекающими...


Про двойную буфферизацию в постгресе не знаете? Любой процесс, читающий данные из ФС, для ОС эквивалентен, независимо от функций, в нем реализованных. А вот "тупо забьет кеш оси" это не так, см. реализацию кэша ФС (по крайней мере, в линуксе, других ОС уже лет пять не видел, ничего о них сказать не могу).

Yo.!

в том то и дело, там где у взрослой без единого телодвижения дается из коробки в ФС приходится изобретать дорогие велосипеды: не дать пользователю просто скопировать файлы БД или записать мусор hex-редактором. до сих пор помню месяцами бегающих фокспро-гайз по этажам прочесывающих сотни компов и разыскивающих, что за гады ежедневно приносят вирус дописывающий свое тело без разбора во все сетевые файлы, в том числе dbf


Интересно, а что помешает вирусу "дописать свое тело без разбора во все сетевые файлы, в том числе" файлы данных СУБД? Вы открыли закон природы, по которому испортить файлы таблиц постгреса вирусам запрещено? :-) Если нет, то не давайте прямого доступа к файлам, и не будет их модификации, независимо от того, что это за файлы.
13 апр 10, 11:37    [8620319]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6644
MBG

Припоминается мне одна система на эскулайт, состоящая из кластера 10-ти ксеонов с 32 ГБ ОЗУ каждый, на которых крутятся in-memory эскулайт БД как раз размером в эту ОЗУ. Для вашего сведения, московский биллинг сотового оператора большой тройки на оракле хранит около 16 терабайт данных и работает на очень мощном "железе". Так что вот не надо заявлять, что мол БД на треть терабайта это такая мелочь, что не заслуживает внимания. У меня пока не возникало потребностей работать с БД более нескольких десятков Гб размером, хотя тестирую проекты обычно на БД в 10 раз больших, нежели их планируемый рабочий размер. т.е. до сотен Гб.

Интересно, а как обстоят дела с резервированием?

MBG

Про двойную буфферизацию в постгресе не знаете? Любой процесс, читающий данные из ФС, для ОС эквивалентен, независимо от функций, в нем реализованных. А вот "тупо забьет кеш оси" это не так, см. реализацию кэша ФС (по крайней мере, в линуксе, других ОС уже лет пять не видел, ничего о них сказать не могу).

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

Насчет кэша см. например msdn createfile и флаг FILE_FLAG_NO_BUFFERING.

Кстати sqlite без кэша работать просто не умеет. В этом тесте, если откинуть BEGIN TRANSACTION - sqlite работал два часа (а mssql - 10минут).

MBG

Yo.!

в том то и дело, там где у взрослой без единого телодвижения дается из коробки в ФС приходится изобретать дорогие велосипеды: не дать пользователю просто скопировать файлы БД или записать мусор hex-редактором. до сих пор помню месяцами бегающих фокспро-гайз по этажам прочесывающих сотни компов и разыскивающих, что за гады ежедневно приносят вирус дописывающий свое тело без разбора во все сетевые файлы, в том числе dbf


Интересно, а что помешает вирусу "дописать свое тело без разбора во все сетевые файлы, в том числе" файлы данных СУБД? Вы открыли закон природы, по которому испортить файлы таблиц постгреса вирусам запрещено? :-) Если нет, то не давайте прямого доступа к файлам, и не будет их модификации, независимо от того, что это за файлы.
[/quot]

В том то и разница, что в клиент-сервере прямого доступа к файлам БД нет никогда. И даже с сервера, потомо что открыты эксклюзивно.
13 апр 10, 13:29    [8621372]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Vinny the POOH
Member

Откуда: Киев
Сообщений: 1525
Там где-то в соседней ветке чел рассказывал, что у него база в пару терабайт и в пару сотен юзеров болтается на фокспро. Мне его даже как-то жалко стало... А скулайт от фоксбейса идеологически мало чем отличается, разве что к выньтузу гвоздями не прибит.
13 апр 10, 15:03    [8622119]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
MBG

Хоть на уровне ячейки делается проверка доступа.

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

MBG

Так что кэш ОС есть всегда, только СУБД в своем большинстве не умеют им пользоваться. И этот кэш ничуть не хуже кэша СУБД, алгоритмы аналогичные используются (см. lru).

о! а мусье случайно располагает данными сколько времени нужно средней субд, чтоб научится пользовать кеш ?
тут недавно Кайт приезжал, нужно было ему рассказать какие глупые в оракле, нет бы примитивный lru пользовать, нет блин напридумывали патентованых алгоритмов и стратегий удержания блоков. а вон sqllite гигабайтами ворочает, а мы не знали

MBG
Припоминается мне одна система на эскулайт, состоящая из кластера 10-ти ксеонов с 32 ГБ ОЗУ каждый, на которых крутятся in-memory эскулайт БД как раз размером в эту ОЗУ.

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

MBG
Так что вот не надо заявлять, что мол БД на треть терабайта это такая мелочь, что не заслуживает внимания. У меня пока не возникало потребностей работать с БД более нескольких десятков Гб размером, хотя тестирую проекты обычно на БД в 10 раз больших, нежели их планируемый рабочий размер. т.е. до сотен Гб.

ясно, как докуришь, идешь заменять блинг большой тройки на sqllite

MBG
А кто вас заставляет собирать статистику черт знает откуда? Поставьте идентичную машину или даже на рабочей машинке сгенерируйте.

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

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

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

устал
но настроение на весь день, спасибо !
13 апр 10, 15:14    [8622195]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Siemargl

Интересно, а как обстоят дела с резервированием?

У кого как. У меня лично - утилита sqlite3-rdiff Для синхронной репликации тоже можно сделать, просто руки не дошли пока, не было надобности.

Siemargl

Кстати sqlite без кэша работать просто не умеет. В этом тесте, если откинуть BEGIN TRANSACTION - sqlite работал два часа (а mssql - 10минут).


Вы разеные режимы смотрите - в эскулайте у вас автокоммит с fsync. Отключите fsync и получите желаемую шустрость.

Siemargl

В том то и разница, что в клиент-сервере прямого доступа к файлам БД нет никогда. И даже с сервера, потомо что открыты эксклюзивно.


Дайте мне рутовый доступ к вашему серверу, и посмотрим, сколько секунд мне понадобится, чтобы прибить все ваши "эксклюзивно открытые" файлы БД.
13 апр 10, 15:43    [8622408]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
Vinny the POOH
А скулайт от фоксбейса идеологически мало чем отличается, разве что к выньтузу гвоздями не прибит.

Блин, а я то думаю, чего меня так и тянет этого аффтара назвать фокспрошником. Аж боялся обидеть человека.
А оно вона как.
13 апр 10, 15:43    [8622415]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Yo.!

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


У вас веб-интерфейс и прочие сервисы тождественно равняются полному доступу к серверу? Меняйте профессию...
13 апр 10, 15:49    [8622459]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
MBG

У вас веб-интерфейс и прочие сервисы тождественно равняются полному доступу к серверу? Меняйте профессию...

нет, лично у меня применение фс-субд в 21 веке тождественно умственной неполноценности применяющего, не зависимо какими интерфейсами пытаются прикрыть убогость этой фс-субд. упрятывание фс-субд за трехзвенкой решает некоторые из самых больших недостатков фс-субд, но простота как известно хуже воровства...
13 апр 10, 16:01    [8622564]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
Yo.!
упрятывание фс-субд за трехзвенкой решает некоторые из самых больших недостатков фс-субд, но простота как известно хуже воровства...

Дык тут даже простоты не наблюдается - лишний слой городить на ровном месте.
Несмотря на то, что трёхзвенки это хорошо и правильно - нужны они вовсе не для того, чтобы родовые травмы прикрывать

А так да, бегал тут помнится Sergey Ch, с криками "фокспро плюс веб-сервисы - ничуть не хуже, а может быть даже и лучше, чем всё остальное вместе взятое"
13 апр 10, 16:37    [8622856]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Pure.....
Member

Откуда:
Сообщений: 54
MBG


SERG1257
Согласен, только вероятность бага в вашем велосипеде куда выше, чем в фиче взрослой СУБД по причине лучшего тестирования последней


Странное утверждение. Есть понятие полноты тестового покрытия, а "лучшее тестирование" - это вы что, верите в исчерпывающее тестирование методом тыка (вручную)? Например, тест модуля работы с ip-адресами:
http://sqlite.mobigroup.ru/artifact/b0c8fcc099
Вы готовы на основе своих знаний о "взрослых СУБД" предложить свой комплект тестов?..

Э-эээ, не понял в чем вопрос. Это предложение помериться у кого тесты лучше? :)
13 апр 10, 18:08    [8623696]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Pure.....
MBG

...
Вы готовы на основе своих знаний о "взрослых СУБД" предложить свой комплект тестов?..

Э-эээ, не понял в чем вопрос. Это предложение помериться у кого тесты лучше? :)


Предложение подтвердить свои утверждения доказательствами. Утверждение, что СУБД лучше, потому что она "взрослая" - это детский сад какой-то.
13 апр 10, 19:21    [8624087]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Yo.!
MBG

У вас веб-интерфейс и прочие сервисы тождественно равняются полному доступу к серверу? Меняйте профессию...

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


Бедный оракл - не посоветовался с вами, покупая файловую СУБД BerkeleyDB, а теперь тратится на ее развитие. А в последней версии еще и движок эскулайта интегрировали для поддержки SQL. Срочно звоните Ларри Эллисону - сообщить, что вы с ним не согласны... Заодно предложите in-memory СУБД TimesTen выкинуть, которую они тоже купили, не посоветовавшись с вами.
13 апр 10, 19:24    [8624108]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
MBG
Pure.....
MBG

...
Вы готовы на основе своих знаний о "взрослых СУБД" предложить свой комплект тестов?..

Э-эээ, не понял в чем вопрос. Это предложение помериться у кого тесты лучше? :)


Предложение подтвердить свои утверждения доказательствами. Утверждение, что СУБД лучше, потому что она "взрослая" - это детский сад какой-то.

Добро пожаловать на tpc.org
13 апр 10, 19:33    [8624142]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
MBG
Yo.!
MBG

У вас веб-интерфейс и прочие сервисы тождественно равняются полному доступу к серверу? Меняйте профессию...

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


Бедный оракл - не посоветовался с вами, покупая файловую СУБД BerkeleyDB, а теперь тратится на ее развитие. А в последней версии еще и движок эскулайта интегрировали для поддержки SQL. Срочно звоните Ларри Эллисону - сообщить, что вы с ним не согласны... Заодно предложите in-memory СУБД TimesTen выкинуть, которую они тоже купили, не посоветовавшись с вами.

ваще дурак
BerkeleyDB назвать ФС.
in-memory database приплести.
срочно санитаров

чего еще там в списке "файловых субд"?
ржунимагу
13 апр 10, 19:38    [8624158]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить