Проприетарные СУБД обречены?

>Файл как сущность вещь лишняя.

Файл есть строка в таблице базы данных. Вы говорите глупость.

>>как вообще в фс определить целостность данных? как можно указать что содержимое такого-то файла должно быть согласовано с существованием другого? целостность может быть только тогда когда фс начнет плотно работать с содержимым файлов

>При записи сохраняется контрольная сумма, если при чтении она не совпала - данные испорчены.

а причем тут контрольная сумма? задача не сохранить данные, а сохранить согласованность

>Синхронизация данных нескольких файлов лежит вне задачи база данных и файловой системы, а кладется она на приложение, создающее логику. В базах данных оно интегрировано и описывается с помощью sql.

если б это было так хорошо то ничего бы не интегрировали

>>Пожалста: вводим три новых функции, files_trx_start(), сommit/ rollback. Если приложение сделало какие-то изменения (создание/запись/удаление файлов) и было убито до того как оно вызвало commit - данные должны быть откачены на их начальное состояние.

> Кстати, так все транзакции в файловых системах и работают. Даже в журналируемой ФС без транзакций такое возможно.

Не совсем. В моем примере можно было бы сделать, чтобы распаковка архива (создание и запись кучи файлов) заканчивалась одним из двух:

1. все файлы созданы и записаны

2. ничего не создано и не записано

В доступных ФС это невозможно.

> It depends, google и прочие с подобными объемами вряд ли смогут работать с обычной базой данных. ФС опять же проще и надежнее (когда-нибудь пробовали вытащить данные из файлов убитых баз данных?).

А смысл, если есть бэкап? Я знаю скажем про amandy, но её настройка в разы сложнее, чем комбинация pg_dump и scp в кроне.

>>Это серьёзно? Ссылку можно?

>http://openfts.sourceforge.net/

>Несовсем "прекрасно", но тем не менее.

Вопрос же был - как поисковый движок прикручивается к любой директории. А в ссылке речь идет о поисковом движке для Postgres (причем об этой разработке даже новость была в свое время на ЛОРе). Или я чего-то не понимаю? Как это подвесить к файловой системе?

To

Dubrovsky * (*) (22.12.2007 22:09:14)

gods-little-toy * (*) (22.12.2007 22:09:34)

вы снова путаете задачу хранения данных и задачу управления логикой их обработки.

Базы данных уже содержат в себе инструмент для этого, он называется sql. Файловые системы нет, но они предоставляют интерфейсы, с помощью которых это можно сделать.

> это та же ниша, что и написанная на sql транзакция в базе данных - это же можно сделать для ext2 и xattrs

Можно, конечно. Но то, что это не сделано - говорит о том, что не особо и нужно.

Ну и транзакции - это только часть того, что нужно. Как насчет ФС с триггерами? :)

>Вопрос же был - как поисковый движок прикручивается к любой директории. А в ссылке речь идет о поисковом движке для Postgres (причем об этой разработке даже новость была в свое время на ЛОРе). Или я чего-то не понимаю? Как это подвесить к файловой системе?

Там просто поисковик, его можно прикрутить к чему угодно. Поисковик работает с данными, положенными в postgres. Он сам их туда и кладет.

>> Файл как сущность вещь лишняя.

> Файл есть строка в таблице базы данных. Вы говорите глупость.

Ась? Я могу выборку из нескоьких таблиц сделать. Что там будет файл? Ноя вообще-то не это имел в виду - а рассказы Раскина про его текстовый редактор - там не было понятия файла вообще.

>>Файл есть строка в таблице базы данных.

Так у нас файловая система реляционная или иерархическая БД? Аналогия не вполне очевидна. Если иерархическая то у нас строк в таблицах нет (как и самих таблиц).

> Базы данных уже содержат в себе инструмент для этого, он называется sql. Файловые системы нет, но они предоставляют интерфейсы, с помощью которых это можно сделать.

Да многое можно сделать, если сильно и много потрудиться, только _зачем_? Это уже всё есть. Интересен не процесс, а результат.

>Ну и транзакции - это только часть того, что нужно. Как насчет ФС с триггерами? :)

Здесь сложнее, но тоже можно - во-первых, уведомления об изменениях объектов, во-вторых, приложение, грамотно обрабатывающее эти изменения.

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

>>уведомления об изменениях объектов

Это что-то вроде inotify в 2.6 ядрах. Кажется, это тоже как-то связано с расширенными атрибутами, которые одновременно появились?

>> Файл есть строка в таблице базы данных. Вы говорите глупость.

>Ась? Я могу выборку из нескоьких таблиц сделать. Что там будет файл?

Таблица - есть директория. Пожалуйста: grep qwery -r dir1 dir2

2rtc

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

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

MSSQL по сравнению с MySQL и PostgreSQL - полный отстой, MSSQL не использует SQL как стандарт, это вообще полный отстой. Тот кто работал с преобразованием данных в MSSQL меня поймет. Эта проблема отсутствует в MSSQL, Oracle. Во-вторых, сравните например мощность Oracle и MSSQL 2005. MSSQL2005 - на редкость жадное к ресурсам и тормознутое гам..но. MySQL при тех же обьемах данных - работает на порядок шустрее, да и ресурсов жрет меньше. А вообще будуще за теми СУБД, которы позволяют безплатно ее использовать при нормальной производительности и администрировании. Уберите поддержку MSSQL (которая единственная из всех бд нормально поддерживается) в средствах разработки и языках программирования от мелкософта - и она никому нужна не будет.

>>уведомления об изменениях объектов

>Это что-то вроде inotify в 2.6 ядрах. Кажется, это тоже как-то связано с расширенными атрибутами, которые одновременно появились?

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

сорри, опечатка в "отсутствует в MSSQL, Oracle", надо "отсутствует в MySQL, Oracle"

> Таблица - есть директория. Пожалуйста: grep qwery -r dir1 dir2

Моих любимых aliasов нет хотя бы как в VMS :) Не говоря уж о представлениях.

>>Аттрбуты появились очень давно

Но линукс с ними научился работать, только с появлением ядра 2.6 (если только не это подразумевается под "давно"). Да и то, там, кажется, остался параметр, который отключает этот функционал.

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

Опять же дело вкуса - ebay например не использует базу данных для логики, а работает с собственным сервером приложений. google вообще не использует базу данных.

Писать на sql проще, чем делать собственный сервер приложений, это является основной причиной.

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

Абсолютно верно, только можно добавить по завершении распаковки записать в xattr какой-нибудь флжак, который после аварийной загрузки будет проверен, и если его нет, то удалить частично распаковынный архив - все как просили :) Только не очень удобно, но возможно.

>Но линукс с ними научился работать, только с появлением ядра 2.6 (если только не это подразумевается под "давно"). Да и то, там, кажется, остался параметр, который отключает этот функционал.

В 2.4 xattrs были точно в xfs и jfs. ext3 не поддерживала, согласен.

>> Таблица - есть директория. Пожалуйста: grep qwery -r dir1 dir2

>Моих любимых aliasов нет хотя бы как в VMS :) Не говоря уж о представлениях.

Кто ищет, тот всегда найдет:

$ export alias_dir_1="dir1 dir2"
$ export alias_dir_2="dir3 dir4"
$ grep qwery -r $alias_dir_1

:)

>>Не говоря уж о представлениях.

Значит, как сделать natural join вам понятно? Не объяните популярно, как это grep-ом делается?

>Значит, как сделать natural join вам понятно? Не объяните популярно, как это grep-ом делается?

Опять вы путаете СУБД и собственно храние данных в базе. Точнее провоцируете.

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

СУБД и sql лучше только тем, что они проще.

>>Сделайте несколько поисков и сохраните их во временный файлы, все точно так же как делает это oracle... Это неудобно, но это возможно.

Вот ваша аналогия "файл=строка,директоря=таблица" и рассыпается. В данном случае файл выступает уже в качестве временной таблицы.

Лишняя это сущность. Все время приходиться вводить дополнительные костыли, типа деления на данные и метаданные и т.д.

>Вот ваша аналогия "файл=строка,директоря=таблица" и рассыпается. В данном случае файл выступает уже в качестве временной таблицы.

Хмм, можно сохранить результаты в памяти приложения - тогда с grep'ом не получится, но это бедут абсолютно те же самое, что делается в субд.

>Лишняя это сущность. Все время приходиться вводить дополнительные костыли, типа деления на данные и метаданные и т.д.

В субд такое же неявное деление - таблица и записи в ней например.

>>СУБД и sql лучше только тем, что они проще.

Ничего себе - "только"!

Потом, не все реляционные СУБД == SQL. Можно BerkleyDB вспомнить, которую используют уже практически везде.

люди, создающие велосипеды grep'ами и придумывающие структуру "БД" из файлов и директорий - неужели вы реально думаете что умнее тех же MySQL которые этим последние 10 лет занимаются?

>>Моих любимых aliasов нет хотя бы как в VMS :) Не говоря уж о представлениях.

>Кто ищет, тот всегда найдет:

>$ export alias_dir_1="dir1 dir2" >$ export alias_dir_2="dir3 dir4" >$ grep qwery -r $alias_dir_1

>:)

Это совсем не то :) Поведение существенно более примитивное.

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

>бинлог, который может сойти как за инкрементальный бэкап, так и дифф.

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

не путай сущности.

> субд вообще обречены, с повсеместным переходом с магнитных хардов на электронные быстрее будет прочитать и распарсить файл с диска, нежели тащить коллосальный костыль в лице субд

Читать Codd's 12 rules.

> Даже лениво вступать в дискус относительно ms vs my

MS SQL ни разу в жизни не видел, слышал много плохого. Бывали вообще страшные истории в которые слабо верится. Так что знающих людей по этому вопросу с удовольствием бы послушал.

>субд вообще обречены, с повсеместным переходом с магнитных хардов на электронные быстрее будет прочитать и распарсить файл с диска, нежели тащить коллосальный костыль в лице субд

Ага. А когда потребуется ACID-ность, то что делать? Файловая система разве что D даёт.

6.2 Replication Implementation Overview =======================================

MySQL replication is based on the master server keeping track of all changes to your databases (updates, deletes, and so on) in its binary logs. Therefore, to use replication, you must enable binary logging on the master server. See *Note binary-log::.

> Файловая система - это костыль. Недоделанная иерархическая СУБД.

+1 Даешь SELECT * FROM "C:\mydb.txt" WHERE id = 2!

> Приведи пример операции, которую ФС на PostgreSQL делала бы лучше чем например ext2.

Поиск видео-фильмов по винту. В фс пришлось бы просмотреть заголовки всех файлов - смотреть не совпадает ли он с заголовком какого-нить известного формата хранения видео. В базе у тебя скорее всего будет функциональня зависимость: file_type <-- file_id Поэтому выборка будет происходить достаточно быстро.

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

> Желание построить файловую систему над DBMS (WinFS anyone??) - это какая болезнь, эпидемии которой случаются в разных средах разработчиков :-)))

Лавры нормальной операционной системы (AS/400) не дают покоя недотепам из Редмонда.

Какому идиоту пришло в голову сказать, что PostgreSQL, в котором даже нет нормального record-based log shipping на 10% отстает от Oracle? Идиоты, вы еще скажите, что хоть кто-то осилил RAC.

Вообще, этот функционал в мире за всю историю человечества полностью смогла реализовать всего одна команда программистов всего один раз - люди в Digital, которые делали кластеры на OpenVMS. Потом Digital портировала это в Tru64 (где до сих пор остается самый гениальный кластер и замечательная AdvFS, которая еще в девяностых умела динамическую реконфигурацию, распределенные блокировки, параллельный доступ, интегрированный LVM (превед, zfs!), снапшоты), а Oracle лицензировала этот код, на основе которого в девятке и выпустила RAC.

А уж про shared-nothing СУБД вроде DB2/390 или Teradata красноглазым вообще не понять. Мозгу думать выше майэскуэля для пыхпыхбебе не поднимается.

>Идиоты, вы еще скажите, что хоть кто-то осилил RAC.

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

> Господа знающие, если я ошибаюсь (мне бы действительно этого хотелось), поправьте. Только давайте на берегу договоримся, не путать понятия "может/умеет" и "готово к продакшн использованию".

с аналитикой _пока_ туговато.

contrib/dblink в postgre есть и работает. есть ещё skytools со своим pl/proxy. это не dblink, в классическом виде, но можно кастрировать до классики вполне.

https://developer.skype.com/SkypeGarage/DbProjects/SkypePostgresqlWhitepaper - маленький документ от малоизвестной компании skype, у которой весь бизнес построен на postgre.

теперь о репликации. slony1 (trigger based replication) вполне "готовы к продакшн использованию". я пользуюсь. mysql репликация на бинарных логах тоже готова. тоже пользуюсь. таблицы до десятка миллионов записей.

у каждой системы репликации есть свои недостатки. mysql (binlogs) не умеет реплицировать базы с n > 1 master серверов на 1 slave. slony1 (postgresql) умеет реплицировать со скольки угодно мастеров на 1 slave, но изменения в схеме базы нельзя производить напрямую на master сервере, необходимо использовать служебные скрипты слонов.

что значит "инкрементальная" в данном контексте мне не очень понятно, потому что принцип настройки и работы репликации везде одинаковый: слить нужные данные с master'a на slave, после чего salve попросит отдать лог транзакций, начиная с определённой позиции. никто каждый раз миллионные таблицы никуда не таскает. и никогда, насколько я знаю, не таскал.

> Какому идиоту пришло в голову сказать, что PostgreSQL, в котором даже нет нормального record-based log shipping

что, и walmgr от skype тоже не умеет ? что-то меня гложут смутные сомненья по этому поводу, поскольку технически возможность делать rbls есть. см.: http://www.postgresql.org/docs/8.2/static/warm-standby.html#WARM-STANDBY-RECORD

>Я вот тут подумал. Если всю работу выполнять на уровне сервера приложений и грамотно использовать разные прикольные штучки типа Хибернета, то какой смысл от фичастых фич того же Оракла, если он должен использоваться как тупое хранилище таблиц?

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

Использование абстракторов допустимо только для передачи данных от пользователя к БД и обратно.

день вендекапца/проприетрашиныкапца на ЛОРе? круто ж васче :) что ни новость, то радость за сообщество :)

>>mysql (binlogs) не умеет реплицировать базы с n > 1 master серверов на 1 slave.

Вроде бы пятёрка уже умеет.

> Вроде бы пятёрка уже умеет.

к сожалению нет, дружище анонимус. либо эта информация тщательно скрывается.

А это тогда что?

6.13 Auto-Increment in Multiple-Master Replication
==================================================

When multiple servers are configured as replication masters, special
steps must be taken to prevent key collisions when using
`AUTO_INCREMENT' columns, otherwise multiple masters may attempt to use
the same `AUTO_INCREMENT' value when inserting rows.

The `auto_increment_increment' and `auto_increment_offset' system
variables help to accommodate multiple-master replication with
`AUTO_INCREMENT' columns. Each of these variables has a default and
minimum value of 1, and a maximum value of 65,535. They were introduced
in MySQL 5.0.2.

These two variables affect `AUTO_INCREMENT' column behavior as follows:

   * `auto_increment_increment' controls the increment between
     successive `AUTO_INCREMENT' values.

   * `auto_increment_offset' determines the starting point for
     `AUTO_INCREMENT' column values.

By choosing non-conflicting values for these variables on different
masters, servers in a multiple-master configuration will not use
conflicting `AUTO_INCREMENT' values when inserting new rows into the
same table. To set up N master servers, set the variables like this:

   * Set `auto_increment_increment' to N on each master.

   * Set each of the N masters to have a different
     `auto_increment_offset', using the values 1, 2, ..., N.

For additional information about `auto_increment_increment' and
`auto_increment_offset', see *Note server-system-variables::.

> А это тогда что?

> 6.13 Auto-Increment in Multiple-Master Replication

а это, мой анонимный друг, Multiple-Master Replication. т.е. 2 сервера - равноправны. я же говорил о случае однонаправленной репликации, когда необходимо с master серверов A, B, С с базами A1, B1, C1 соответственно, сливать данные на один slave S в базы sA1, sB1, sC1. делать такие вещи нужно, например, для обеспечения горячего резерва, где 1 резервный сервер обслуживает n основных.

в случае с trigger based слонами и postgresql такой финт ушами можно сделать легко, чему несказанно рады те, кто даёт деньги.

в случае с mysql, необходимо иметь по одному резервному серверу на каждый основной, чему инвесторы рады в значительно меньшей степени. даже если им объяснить, что резервные мощности будут использованы для scale-out, который нужен далеко не всем и не всегда.

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

ещё вопросы ? всё таки редко на lor встретишь адекватного анонимуса, поэтому на что смогу, отвечу :)

> К чему приводит хранение бизнес-логики cнаружи, можно видеть на примере поделий типа 1С

а к чему приводит хранение бизнес логики внутри, видимо, можно ощутить на примере криво списанных денег, со счёта абонента оператора сотовой связи ?

отлаживать многоэтажные процедуры на (transact|pl)sql не самая тривиальная задача, да. а во многих случаях и просто невозможная. поэтому на вашем месте я бы не был столь категоричен.

> ещё вопросы ?

Ага, хоть я и не анонимус %)

В чем разница между реплицированием нескольких БД в один сервер (как я понял, это то, о чем ты говорил) и реплицированием нескольких БД в несколько серверов, запущенных на одной физической машине?