Re: Бред рекурсивной кобылы
Алексей Вишняков [EMAIL PROTECTED] сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] Вы не могли бы развернуть ответ, пожалуйста? Любой способ хранения дерва, базирующийся на ссылках так или иначе может порождать рекурсию. Причём тут особо не важно ссылается родитель на детей или наоборот или и то и другое сразу. Для того чтобы дерево не содержало рекурсию нужно отказаться от ссылок. Методов тут масса, но у всех есть недостатки связанные со скоростью, сложностью обработки и т.д. Самое простое - хранить маршрут для каждого нода. Например самый тупой: Ключ ID INTEGER, PARPATH VARCHAR, храним типа так IDPARAPATH 1 '' 2 '1' 3 '1' 4 '1.2' 5 '1.2.4' 14'10.2.7.1345.67 ' Тут циклов уже не будет, но зато сложно организовать целостность - могут появится мусорные записи, реально в дереве не находящиеся. Методов хранения путей тоже много. Для некторых можно и ссылочную целостность организовать.
Re: Спецы посоветуйте...
Привет, Vyacheslav! Вы пишешь 02 апреля 2008: VAS 1диск XOR 2диск XOR 3диск XOR 4диск = 5 диск (на нем только результат XOR) нет. -- With best regards, Alex Cherednichenko.
На: Спецы посоветуйте...
Накрылись 2 диска в 5-дисковом массиве raid-5. Raid-контроллер. При старте винда не видела диска. Зашли в биос и сказали rebuild. Диск появился, но винда советует его отформатировать, потому как ничего на нем нет. Это уже клиника, или еще можно что-то сделать? Сейчас из backup восстановили данные для 5 рейда смерть 2 дисков = смерти рейда. там вкратце так все: 1диск XOR 2диск XOR 3диск XOR 4диск = 5 диск (на нем только результат XOR) любой из дисков получается так: 3диск = 1диск XOR 2диск XOR 4диск XOR 5диск поэтому потерять можно только 1 из них. может конечно что-то поменялось сейчас и рейд-5 стал работать по-другому, но мало верится. попытайся связаться с производителем рейда. а ребилд рейда, кажися, это создание его заново.
Re: Спецы посоветуйте...
Привет, Vyacheslav! Вы пишешь 02 апреля 2008: VAS ответ не раскрыт )) Написанное тобой и процитированное мной, мягко говоря, лажа. VAS неужели уже можно восстановить рейд-5 когда 2 из 5 дисков поломаны? На автомате - нет. -- With best regards, Alex Cherednichenko.
На: Спецы посоветуйте...
нет. ответ не раскрыт )) неужели уже можно восстановить рейд-5 когда 2 из 5 дисков поломаны? можно подробнее?
Re: Спецы посоветуйте...
Привет, Мадорский! Вы пишешь 02 апреля 2008: На автомате - нет. МГВ Я так понимаю, что это приговор. Дело в том, что сверху этот диск был МГВ зашифрован Sicret Disk Server. Поэтому вручную чего-то там восстанавливать МГВ как-то врядли чего получиться. Позвони в СофтДжойс, они даже без ректо-термального анализатора выковыривают информацию из самых безнадёжно-больных носителей информации. (речь вестимо о железяках) зы: но дорого(очень) -- With best regards, Alex Cherednichenko.
Re: Спецы посоветуйте...
На автомате - нет. МГВ Я так понимаю, что это приговор. Дело в том, что сверху этот диск был МГВ зашифрован Sicret Disk Server. Поэтому вручную чего-то там восстанавливать МГВ как-то врядли чего получиться. Позвони в СофтДжойс, они даже без ректо-термального анализатора выковыривают информацию из самых безнадёжно-больных носителей информации. (речь вестимо о железяках) зы: но дорого(очень) Не, оно того не стоит. Бэкап был налажен. Пропали файлы, которые в бэкап не входили. Пользовательские фотки, о которых они очень печалятся, кое-какие дистрибутивы программ - это разыщется по мере необходимости ну и т.д. Единственное - похерились файлы MS-SQL. У меня в нем OLAP кубы всякие строились. Бэкап был настроен (по запарке видимо) на этот же диск... :) Ну это на 2-3 дня работы чтоб вспомнить и настроить заново. With b/r. Gleb.
Re: Спецы посоветуйте...
Hello, Alex! Alex Cherednichenko wrote: Привет, Vyacheslav! Вы пишешь 02 апреля 2008: VAS 1диск XOR 2диск XOR 3диск XOR 4диск = 5 диск (на нем только результат XOR) нет. да. к двойным отказам усточив RAID 6, а не RAID 5. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Спецы посоветуйте...
Привет, Dmitri! Вы пишешь 02 апреля 2008: DK да. Шо да? Написана чушь. О двойных отказах речь не идёт. -- With best regards, Alex Cherednichenko.
Re: Спецы посоветуйте...
Hello, Alex! Alex Cherednichenko wrote: DK да. Шо да? Написана чушь. О двойных отказах речь не идёт. где написана чушь? давай тогда разбираться, что такое двойной отказ, и как распределяются данные и контрольные суммы в RAID 5... 2 умерших диска из 5-ти - это не двойной отказ? -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Спецы посоветуйте...
Привет, Dmitri! Вы пишешь 02 апреля 2008: DK где написана чушь? давай тогда разбираться, DK что такое двойной отказ, и как распределяются DK данные и контрольные суммы в RAID 5... DK 2 умерших диска из 5-ти - это не двойной отказ? Я где-то упоминал двойные отказы? Претензии к процитированной строчке. Ибо чушь. Готов спорить? -- With best regards, Alex Cherednichenko.
Re: Спецы посоветуйте...
Здравствуйте, Алекс. DK где написана чушь? давай тогда разбираться, DK что такое двойной отказ, и как распределяются DK данные и контрольные суммы в RAID 5... DK 2 умерших диска из 5-ти - это не двойной отказ? Я где-то упоминал двойные отказы? Претензии к процитированной строчке. Ибо чушь. Готов спорить? Я спорить не буду, просто поинтересуюсь - как тогда _на_самом_деле_ работает система сохранения целостности данных на массиве RAID 5й версии с пятью жёсткими дисками? -- -- Norritt, mailto:[EMAIL PROTECTED]
Re: Спецы посоветуйте...
Привет, Алексей! Вы пишешь 02 апреля 2008: АВ Я спорить не буду, просто поинтересуюсь - как тогда _на самом деле_ АВ работает система сохранения целостности данных на массиве RAID 5й АВ версии с пятью жёсткими дисками? http://www.ixbt.com/storage/raids.html -- With best regards, Alex Cherednichenko.
Re: Спецы посоветуйте...
Alex Cherednichenko пишет: DK да. Шо да? Написана чушь. О двойных отказах речь не идёт. Ну почему сразу лажа, чушь? На уровне показать _модель_ на пальцах - вполне сойдет.
А вот кому кластеры-шмастеры тут надо?
Привет! Дискламбер - трава у нас бывает разная, кому не нравится - не нюхайте. Некоторые осведомленные люди (типа Джима Старки) в своих мемуарах писали, что interbase был изначально придуман как сервер для кластеров. Так как у некоторых товарищей до сих пор существуют или абсолютно невнятные представления о том, что такое кластеры и с чем их едят, или отсутствуют такие представления вообще, я и затеял эту ветку. Я не буду тут сыпать определениями (кому надо - погуглит), а просто расскажу о том, что такое кластеры, с чем их едят и какая от этого польза для БД. Итак, кластер - это группа компьютеров, которые работают совместно над какой-нибудь общей задачей. В некоторых случаях, кластером могут называть группу кластеров. Звучит немного рекурсивно, но это так. Есть много типов кластеров, но нас интересуют только три: 1) отказоустойчивые кластеры (High-availability clusters, HAC) 2) кластеры с балансировкой нагрузки (Load balancing clusters, LBC) 3) высокопроизводительные кластеры (High-performance clusters, HPC) (кому хочется подробностей - http://ru.wikipedia.org/wiki/Кластер а оттуда на кластер в виде группы компьютеров). Как обычно, нам бы таблетку от жадности, да побольше: все хотят и отказоустойчивый, и чтобы нагрузку сам распределял и работал быстро-быстро, быстрее чем Крэй (есть такие миленькие машинки с 5-6к процессоров, общей памятью в пару терабайт и неразглашаемой стоимостью). При этом, все, кто краем уха слышал что-то о кластерах, считает, что это решение всех проблем - Давайте водрузим нашу прогу на кластер и оно за нас работать будет быстрее. Должен вас очень сильно огорчить - это далеко не так. И я даже не буду говорить о том, что доставить, настроить и обслуживать такого монстра ой как тяжко. SUN Microsystems вам доставит свой суперкомпьютер о 72 головах (каждая голова может быть 6-ти ядерной и более) в любую точку мира в течение месяца. И даже настроит - бесплатно. Но вы все равно не купите :) Если кратко, то отказоустойчивый кластер является таковым за счет того, что в случае чего в строй вступают запасные узлы. Но при этом чудес не бывает - если узел чего-то там насчитал клиенту, но не успел отдать и упал - то клиент ничего не получит. Но если обратится еще раз - то все будет клева. Сами попробуйте ответить, подходит ли вам это при работе с БД. Да, на всех машинах-узлах файл БД как буд-то бы один и тот же - специальный драйвер ФС делает всю работу по реальной записи файла прозрачной для приложения. Если сказать кратко - то это как зеркальный RAID. Только если в RAID не практикуется делать 1000 дисков в зеркале, то тут вполне себе возможно, все зависит от потребностей задачи. На основе модели, которая описана выше, не очень сложно представить себе, как работает кластер с балансировкой нагрузки - так как все узлы являются зеркалами друг друга, то можно Васе отдать на растерзание узел А, а Маше - узел Б и все будут довольны (ну кроме менеджера кластера, которому придется это все дело синхронизировать, лочить и заниматься всякими остальными извращениями). Говорят, что некоторые БД умеют делать такие извращения. Только чудес, как я уже говорил, не бывает. Представляете себе, что будет, если 2 ноды упадут в то время как пользователи интенсивно меняют данные? Веселуха разбираться в той каше, которая получится, будет еще та. А бэкапы, как известно, это удел трУсов. Бугага (у Коваленко другой бугага, поэтому его копирайты не ставлю). Третий тип кластеров к БД вообще никакого отношения не имеет. Это числодробилки. Вы забыли свой 18 символьный пароль? Тогда вам сюда. Хотите умножить матрицы 1х1 между собой? Пожалста, резервируйте время - где-то была инфа, что стоит около 10 центов час. Одного процессора. При покупке от недели и больше - скидки. Знакомый физик ездил в Швейцарию считать осаждение чего-то там (вроде атомов металлов) на различные поверхности. Считали взаимодействие 10 миллионов атомов или что-то около того. Крей пожужжал немного и выплюнул им пару двд данных - они их потом чуть ли не два года изучали. Более того, для этих числодробилок и проги надо писать соответственно - с учетом MPI API. Есть конечно альтернатива классическому HPC - MOSIX (http://www.mosix.org/) Для академических нужд бесплатно, для коммерческого использования что-то около 1к баксов на 10 узлов - копейки по сути дела. Представляет из себя патч для Линуха (виндузятники багровеют от зависти, я знаю сколько стоит дата-центр у мелкомягких), который позволяет 10-20-100 компов или кластеров (да-да, рекурсия) превратить как бы в один суперкомпьютер - у которого много процессоров. Вру. С точки зрения приложения это даже не важно много или один - многие программы запускаются нативно и ничего не замечают - это проблемы менеджера кластера, как выделить память и процессорное время задаче. Как только я познакомился с MOSIX тут же загорелся идеей. Потом понял, что все же есть подвох. Общей памяти нету. (Понятно почему классик держит все локи в файле? ;-) ) Если прога использует удаленные сокеты - то она не
На: Спецы посоветуйте...
АВ Я спорить не буду, просто поинтересуюсь - как тогда _на самом деле_ АВ работает система сохранения целостности данных на массиве RAID 5й АВ версии с пятью жёсткими дисками? Существует два основных типа кодирования, которые применяются в избыточных дисковых массивах - это дублирование и четность. Дублирование, или зеркализация - наиболее часто используются в дисковых массивах. Простые зеркальные системы используют две копии данных, каждая копия размещается на отдельных дисках. Это схема достаточно проста и не требует дополнительных аппаратных затрат, но имеет один существенный недостаток - она использует 50% дискового пространства для хранения копии информации. Второй способ реализации избыточных дисковых массивов - использование избыточного кодирования с помощью вычисления четности. Четность вычисляется как операция XOR всех символов в слове данных. - таким же образом это делается, к примеру, и в архиваторах разных. ну может я привел сильно упрощенный вариант. я просто хотел показать на пальцах как это работает.
Re: Спецы посоветуйте...
Привет, Vyacheslav! Вы пишешь 02 апреля 2008: VAS таким же образом это делается, к примеру, и в архиваторах разных. VAS ну может я привел сильно упрощенный вариант. VAS я просто хотел показать на пальцах как это работает. Это не так работает. Контрольные суммы в RAID-5 это не примитивный XOR. На кой хер авторы статьи вообще о нем заикнулись, неизвестно. Наверное тоже хотели на пальцах... Кроме того, цельный диск для хранения контрольных сумм в случае RAID-5 не выделяется. -- With best regards, Alex Cherednichenko.
Re: А вот кому кластеры-шмастеры тут надо?
On Wed, 02 Apr 2008 18:30:42 +0400, Sergey Mereutsa [EMAIL PROTECTED] wrote: Мне - чтобы быстрее работало. Нам вот конкретно кластер нафиг не нужон. Процы как не особо важны - они успевают. А перестанут - ещё добавим. ЕщёБолееМногоЯйцевых. Проблема в дисковой системе, там вся нагрузка скапливается пока. Как появится Fusion ioDrive в свободной продаже - тогда может чего другого захочется. -- Сергей Смирнов.
Re: Спецы посоветуйте...
On Wed, 02 Apr 2008 17:54:51 +0400, М.Королев [EMAIL PROTECTED] wrote: На уровне показать _модель_ на пальцах - вполне сойдет. Потому и не сойдёт, что указанная строка - это скорее RAID4, а вовсе не 5. -- Сергей Смирнов.
Re: А вот кому кластеры-шмастеры тут надо?
Hello, Sergey! Sergey Mereutsa wrote: Есть много типов кластеров, но нас интересуют только три: 1) отказоустойчивые кластеры (High-availability clusters, HAC) по-моему, еще называют Fail-safe. грубо говоря, основная цель это дублирование оборудования. Что, думаете все, вешалка и надо завернуться в белую простынь? Не дождетесь. А вот что можно сделать в плане применения к БД, я постараюсь рассказать чуть позже - если общественность выразит свое мнение по поводу всего вышенаписанного и скажет, для чего им все-таки нужен кластер - чтобы не падало, быстрее работало или все вместе? давай! -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: GUID как первичный ключ
Здравствуйте, Nikolay Ponomarenko IK Как повлияет на производительность замена первичного ключа типа BIGINT IK на GUID? Стоит ли вообще это делать? Станет немного медленнее - распухнет бд, индексы, больше чтений, больше памяти. Нельзя будет использовать такое свойство автоинкрементируемого ПК как монотонное возрастание, что в общем неправильно, но иногда удобно :) Вот пребываю в муках как раз по такому же поводу... Только не с GUID, а, все-таки с bigint. Ход мысли по простейшей ветке: Каждой базе-точке выделяем PID. Баз-точек заведомо не больше, скажем, чем 1000, значит значения 0PID1000. Тогда ID можно генерить как ГенераторТаблицы *1000 + PID. Тогда получаем общий непересекающийся ID через все точки для одной таблицы. Кстати, сделаем СуперБуперГенератор один на все таблицы, и чем тогда это отличается от GUID, кроме как компактностью? хотя зачем оно надо... Альтернативный вариант: на каждой записи свой собственный человеческий ID, плюс поле ID_EXTERN ( если запись создана в этой базе-точке, то = ID, если принята из другой базы-точки, то =ID той базы, откуда принято). Ну, опять же, третье поле PID надо, которое идентификатор базы-точки. Итого три поля: одно - нормальный автоинкрементный ключ, вторые два в паре являют собой то же самое, что в варианте 1 - уникальный ключ по всем базам-точкам. Кажется, что вариант 2 слегка сложнее в реализации и слегка путаннее в логике, хотя, как преподнесешь это юзерам - зависит от клиентского приложения уже. Вариант 1 в этом смысле куда проще: есть число 123001 - сразу ясно, что эта запись создана в пункте 1 с помощью значения генератора 123. И заведомо известно, что нигде эта запись не повторится, можно вливать в любую из точек безбоязненно. Выглядит, вроде, приятнее вариант 1 (полей меньше, а с ними и индексов, до юзеров доводить логику проще). Одно мучает: в варианте 1 новые записи создаются как-бы вперемежку, не последовательно, а втыкаются друг между другом. Не создаст это проблем в скорости поиска записей по первичным ключам? Типа дефрагментации первичного ключа, что ли? Или это у меня гонки все из класса десктопных таблиц? Короче: есть подозрение, что абсолютно незнакомый мне термин свойство монотонного возрастания как раз про эти проблемы с вариантом 1 :) Не одарит кто-нибудь советом (ну про убей себя я знаю)? В уважением Владимир
Re: А вот кому кластеры-шмастеры тут надо?
Hello, Sergey! You wrote on Wed, 2 Apr 2008 17:30:42 +0300: SM Дискламбер - трава у нас бывает разная, SM кому не нравится - не нюхайте. SM Что, думаете все, вешалка и надо завернуться SM в белую простынь? Не дождетесь. А вот что можно SM сделать в плане применения к БД, я постараюсь SM рассказать чуть позже - если общественность выразит SM свое мнение по поводу всего вышенаписанного и SM скажет, для чего им все-таки нужен кластер - чтобы SM не падало, быстрее работало или все вместе? Хотелки обычно (имхо) развиваются таким образом: 1. Сначала мы хочем, чтоб наши данные не терялись никогда. Организуем систему бэкапов (несмотря на удел трусов :) ). 2. ... и работа не останавливалась ни на секунду. Делаем отказоустойчивый кластер. 2. Смотрим на всю эту груду железа и думаем блин, а нельзя ли это использовать более эффективно, не просто как тупой резерв железа? Пытаемся распределять нагрузку. ... Давай, пиши. В общем, всё это я слышал/знаю, но прочитать еще раз - вреда не будет. И пишешь хорошо. Доходчиво. -- Alexander A. Venikov, Tobolsk, Russia
Проблемы с установкой FirebirdCS-2.0.3.13095-0.i686.tar.gz
При установке FirebirdCS-2.0.3.13095-0.i686.tar.gz он жестко устанавливается в папку /opt/fb20cs и никак не реагирует на смену путей в файлах конфигурации \bin \fb_config (видимо потому, что этот путь прописан в бинарнике \bin \fb_inet_server)... Непорядок!
Re: А вот кому кластеры-шмастеры тут надо?
Что, думаете все, вешалка и надо завернуться в белую простынь? Не дождетесь. А вот что можно сделать в плане применения к БД, я постараюсь рассказать чуть позже - если общественность выразит свое мнение по поводу всего вышенаписанного и скажет, для чего им все-таки нужен кластер - чтобы не падало, быстрее работало или все вместе? Лично мне кластер и даром не нужен. :) Но автор пишет весьма интересно, не говоря уж о том, что делает очень полезное дело и дополнительное спасибо лишним не будет.
