Re: [room] безумные (банальные?) идеи
16 февраля 2011 г. 0:21 пользователь Денис Черносов denis0...@gmail.com написал: 2011/2/15 Алексей Синицын asinitsins...@gmail.com: Программисты уже потихоньку понимают что использовать БД удобнее чем plain files, и в эту сторону начинается активное движение. Я много на эту тему размышлял и пришёл к своему базовому понятийному кирпичику, от которого вытанцовываются все остальные выводы. Имя ему - контекст. См. http://ru.wikipedia.org/wiki/Контекст и особо обратите внимание на строчку: Любое событие происходящие в жизни субъекта интерпретируется исходя из контекста ситуации отраженной в *памяти* субъекта Контекст это хорошо. Но если мы потянем за эту ниточку, то можем утянуть далеко. Если мы начнём выяснять что такое контекст, то найдём что это текст, просто относящийся к текущему как внешний. Естественно попытаться уточнить что такое текст, и тут мы найдём что текст это дамп информации, которая, в свою очередь является моделью. Модель, которую строит ЦНС живого организма, то есть, вне нас информации не существует вообще. А обмен информацией это синхронизация моделей отдельных людей. Любые наши понятия, любые наши действия и особенно ВЗАИМОдействия - модельны и контекстны. Память и время на обработку - ограничены. А мир - бесконечен. cite Сначала он находил это забавным. Он изобрел закон, который с юмором, подобным закону Паркинсона, утверждал, что количество рациональных гипотез, способных объяснить любое данное явление, бесконечно. Ему нравилось никогда не испытывать недостатка в гипотезах. Даже когда все его возможные методы экспериментальной работы, казалось, заводили в тупик, он знал, что если просто сядет и повозится с работой достаточно долго, то, конечно же, появится еще одна гипотеза. И она всегда появлялась. И только месяцы спустя после того, как он придумал этот закон, начали возникать кое-какие сомнения по поводу его юмора или полезности. /cite Роберт М. Пирсиг Чем более громоздок и универсален контекст - тем более дороги его освоение, поддержка и использование. Слишком примитивный контекст не позволяет реализовать адекватную модель. Бесконечный контекст - потребует бесконечной памяти и сведёт на нет все плюсы от его использования. Истина где-то между, но тысячелетия практики обработки данных показывают, что везде, где это возможно - лучше идти по пути максимального упрощения модели, требующей соотв. минимального контекста. И формализации бизнес-процессов. Плюс механизм расширения функционала под каждую конкретную задачу. Да. Правильная модель будет минимальными средствами описывать максимально возможное число явлений. Простота, точность и ёмкость. Описывая общие случаи, оставляя частные как информацию личного характера, не представляющую общего интереса. Нуу.., кроме бизнес-процессов. Про это ничего не могу сказать :) Возможно всё то же самое. А запихивать всё подряд в одну кучу - это вообще не решение, если нет ответа на вопрос как эти данные будут использоваться. Всё, что я прочитал в ваших постах - это, извините, плюшкинство. Пусть лежит на всякий случай разный хлам в огромной куче. Не совсем. Наверно можно сказать скорее так: мне не нравится большое количество баз данных в системе, на каждый дигикам по СУБД. Мне кажется разумной идея свести их в одну. Почти не сомневаюсь что кроме простой экономии это даст и другие полезные побочные эффекты. Формат и объем метаданных - это отражение модели и контекста. Индексирование метаданных = выделение контекста. Контекст выделяется для облегчения работы с данными, но когда индексы становятся сравнимыми по объему с исходными данными - нафиг они не нужны! В какой-то момент нужно останавливаться и доставать таблетки от жадности. В какой то момент дампы (тексты) станут мало нужны и обращения к ним станут происходить крайне редко. Работа с информацией будет проходить на уровне метаинформации, содержания. Но это будет нескоро. Думаю я не доживу. В народ идут только достаточно простые НЕуниверсальные контексты, привязанные к конкретным задачам. Google waves в народ не пошёл, хотя мегамогучая фиговина, стирающая грани между большинством протоколов и хранилищ. А электронная почта никак не убивается, несмотря на все её очевидные недостатки. Ой, видел я эти волны. Может и мощно, но ничего не понятно и всё тормозит. Видеохостинг развивается достаточно независимо от календаря. И т.д. и т.п. Специализация оказывается дешевле универсализации. А потом приходит общая теория, которая включает в себя все предыдущие как частные случаи :) Впрочем, повторно вспоминаю akonadi + strigi. Поставьте в индексацию системные файлы и они будут ими индексироваться. Вот только зачем? Что вы надеетесь чудесным образом наковырять в служебных файлах? Если у вас есть ответ на этот вопрос - автоматизация уже не проблема... а задача. Причём, типовая. Ну можно системные и не индексировать. Но на фоне файлопомоек, эти два-три гигабайта кажутся несущественными.
Re: [room] безумные (банальные?) идеи
On Wed, Feb 16, 2011 at 08:45:57PM +0300, Алексей Синицын wrote: Наверно тогда лучше так. Мне говорили что база SQL это один файл. Это не соответствует? И если сответствует, то что произойдёт если во время записи пропадёт питание? Да, мы вроде про домашние устройства, где возможно отсутствие ИБП. ФС убиваются в хлам, насколько мне известно, не так часто. Чаще теряется часть файлов. Большее количество файлов может дать большую устойчивость. БД бывают разные. Некоторые в одном файле (как sqlite), некоторые в группе файлов (как постгрес или mysql), некоторые умеют работать на raw disk (как оракл). И у них есть свои средства восстановления после сбоев. Да, наверно можно базу и на сыром разделе держать, но тогда СУБД так или иначе всё равно вынуждена будет выполнять функции ФС. Возможно дешевле оставить ФС как носитель. Для БД которые в одном файле, например, не придется. Потому что им от ФС нужно очень-очень мало. -- С уважением, Денис http://mithraen.ru/ signature.asc Description: Digital signature ___ smoke-room mailing list smoke-room@lists.altlinux.org https://lists.altlinux.org/mailman/listinfo/smoke-room
Re: [room] безумные (банальные?) идеи
16 февраля 2011 г. 3:05 пользователь Денис Смирнов mithr...@freesource.info написал: On Wed, Feb 16, 2011 at 12:21:21AM +0300, Денис Черносов wrote: Истина где-то между, но тысячелетия практики обработки данных показывают, что везде, где это возможно - лучше идти по пути максимального упрощения модели, требующей соотв. минимального контекста. И формализации бизнес-процессов. Плюс механизм расширения функционала под каждую конкретную задачу. ППКС. Простота и пустота не одно и то же. Когда простая модель описывает многое - это очень ценная модель. Когда модель описывает один частный случай - такая модель мало стоит независимо от её сложности. Формат и объем метаданных - это отражение модели и контекста. Индексирование метаданных = выделение контекста. Контекст выделяется для облегчения работы с данными, но когда индексы становятся сравнимыми по объему с исходными данными - нафиг они не нужны! В какой-то момент нужно останавливаться и доставать таблетки от жадности. Иногда индексы нужны даже если их объем существенно превышает объем данных. Суть индекса в получении _быстрого_ ответа. И потому требования к нему зависят исключительно от используемых процессов, и могут быть никак не связаны с размером данных. Индексы нужны хотя бы потому, что это, как верно замечено выше, метаинформация. То есть, модель более общего характера, что очевидно более ценно. И с чем манипуляции будут происходить более эффективно. Google waves в народ не пошёл, хотя мегамогучая фиговина, стирающая грани между большинством протоколов и хранилищ. А электронная почта никак не убивается, несмотря на все её очевидные недостатки. Google waves не пошел потому что неочевиден. Гугль не смогли создать простые и эффективные usecases. Во! Например, я, как простой нормальный человек, посмотрел и ужаснулся с этого их чатика. Правда потом мне объяснили, что это у гугля такие одноклассники, что он просто нашёл в социальных сетях один фатальный недостаток. Но даже после этого я не осилил, впрочем возможно уже потому что и одноклассниками не пользуюсь. Видеохостинг развивается достаточно независимо от календаря. И т.д. и т.п. Специализация оказывается дешевле универсализации. А в ходе это специализации рождаются универсальные технологии (memcached в web -- самый известный пример). Ну или тот же nginx :) Да, да! Надо сделать одну базу, в которой будут записи для каждого файла. И к каждому будет бирка: системный, пользовательский, музыка, видео, текст, можно несколько бирок. Потом ещё, для каждого типа опять горсть бирок. Зуб даю, из этого сейчас разовьётся что нибудь новое и универсальное. Говорите такое уже есть? А я могу к этому аконади или к стриги, к биглю, если он ещё живой, как к бэкенду, подключить проигрыватель музыки, прсмотрщик изборажений? А что, в случае нескольких пользователей это опять куча баз у кучи СУБД? Впрочем, повторно вспоминаю akonadi + strigi. Поставьте в индексацию системные файлы и они будут ими индексироваться. Вот только зачем? Что вы надеетесь чудесным образом наковырять в служебных файлах? Если у вас есть ответ на этот вопрос - автоматизация уже не проблема... а задача. Причём, типовая. Вот формулирование нужных процессов, а также удобный инструмент автоматизации их (на уровне пользователь может сконфигурять сам без команды крутых спецов с суммарной з/п 50k$/месяц) и есть проблема. Такие универсальные вещи можно конфигурять и спецами. Чем универсальнее, тем шире применение. Ядро под себя уже далеко не каждый пересобирает, а патчат и того меньше. ___ smoke-room mailing list smoke-room@lists.altlinux.org https://lists.altlinux.org/mailman/listinfo/smoke-room
Re: [room] безумные (банальные?) идеи
15 февраля 2011 г. 22:30 Денис Смирнов написал: БД на многих задачах и так сильно быстрее чем обычные FS. Кроме того в БД есть фишки недоступные в FS, например транзакции. ZFS? С точками восстановления и откатами? Вроде бы те же самые транзакции :). -- С уважением, Ринат Биков. ___ smoke-room mailing list smoke-room@lists.altlinux.org https://lists.altlinux.org/mailman/listinfo/smoke-room
Re: [room] безумные (банальные?) идеи
On Wed, Feb 16, 2011 at 10:43:52PM +0300, Rinat Bikov wrote: RB ZFS? С точками восстановления и откатами? RB Вроде бы те же самые транзакции :). Ну ZFS это уже несколько... э... необычная FS. С учетом того что у нее и LVM свой, и вообще она разве что кофе варить не умеет. -- С уважением, Денис http://mithraen.ru/ signature.asc Description: Digital signature ___ smoke-room mailing list smoke-room@lists.altlinux.org https://lists.altlinux.org/mailman/listinfo/smoke-room
