Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8 9 10 .. 13   вперед  Ctrl
 Re: Ни на что не похожая БД  [new]
Cane Cat Fisher
Member

Откуда:
Сообщений: 1809
интересующаяся_мнением
Версионник - да, похоже. А можно поподробнее о недостатках?


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

интересующаяся_мнением
сегодня все-таки начинает наблюдаться и обратная тенденция: начали выплывать альтернативные стандартным реляционным базам решения. Согласна в контексте "под каждую отдельную задачу". Но вот если попытаться выделить классы задач?


Я еще раз хочу подчеркнуть: специализированные решения возможны, и в каких-то аспектах могут быть технически совершеннее стандартных. Но в данном случае опасение вызывает не технические параметры системы, а именно то, что она поддерживается 2.5 человеками. Что будет с системой, если эти человеки уедут в Канаду, или захотят стать джазовыми музыкантами?

К сожалению, часто даже технически передовые и совершенные решения умирают, лишь потому, что оказались "не в струе" рынка. Вспомнить ту же OS/2.

интересующаяся_мнением
У них, к примеру, есть такой режим песочницы.


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

интересующаяся_мнением
Насчет переноса на стандартный SQL-сервер. У них связь реализована. Т.е. есть API для цепляния и к обычному серверу. Но для реализации прикладных задач они этим не пользуются - говорят неудобно. Используют связку только если интеграция нужна.


Естественно, если у них вся логика построена на навигационном доступе, то SQL-сервер для них неудобен, и при применении "в лоб" даст только тормоза и неудобства. Нужно сильно переделывать потроха.
29 авг 11, 15:11    [11195460]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
интересующаяся_мнением
Gluk (Kazan)
пропущено...

Как то так?

Да, по эффекту примерно похоже. Нууу... Oracle наверно может все, но это очень дорого, и по стоимости и по обслуживанию. Согласитесь.. небольшая конторка вообще без админов его себе позволить не может.


Небольшая конторка без админов может позволить себе нанять админов, которые поставят Postgress. С ним и 1C кстати дружит
29 авг 11, 15:16    [11195501]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
интересующаяся_мнением
Я пытаюсь немного абстрагироваться от своих знаний и действительно посмотреть на систему непредвзято.


Это очень вредно для (финансового) здоровья - абстрагироваться от знаний
29 авг 11, 15:18    [11195523]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
интересующаяся_мнением
Dimitry Sibiryakov
пропущено...

Такое возможно в двух случаях:
1) Транзакции полностью сериализованы и идут исключительно последовательно;
2) Хранится индивидуальный список принятых транзакций.

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

Какой случай реализован в Вашей системе?

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


Можно не спрашивать, это нумер (1)
29 авг 11, 15:20    [11195543]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Yo.!
просто совсем без блокировок на некоторых задачах процент неудачных транзакций зашкалит за все разумное.

Согласна полностью. Поэтому для себя я изначально ограничиваю класс задач, для которых данная архитектура применима. Никто и не говорит что это универсальное решение.
Насчет неудачных транзакций, - мне вот еще такая идея приходила в голову: у нас же клиент видит все обновления в локальной базе. В теории, если мы в этой архитектуре проектируем систему, которая предполагает большое количество апдейтов, то нам ничего не мешает чекать обновление и подсовывать их операционистке пока она ворон считает. Т.е. действовать, так сказать, превентивным методом. Это должно сократить неудачные транзакции на стороне сервера. Но тоже до определенного предела конечно. Думаю, сотню операционисток у нас есть шанс обработать, а вот систему, автоматом гонящую потоки данных откуда-то, конечно уже нет.

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

Может, но, во-первых это критично только в случаях конфликта на обновление. Если идет массовая вставка данных - какая разница в каком порядке они вставятся? А при конфликте обновления - см. чуть выше, как эту ситуацию можно минимизировать. Вы подумайте еще вот о чем: если у вас клиент-сервер классический, вы вообще не сможете отследить такую ситуацию с конфликтом обновления. Сервер просто перезапишет данные поверх и все. Разве нет?
29 авг 11, 15:21    [11195559]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
интересующаяся_мнением
Поэтому и хочу коллективного мнения и критики подхода. :)
Только аргументированной.


1. Распишите, что происходит когда падает сервер и как обеспечивается отсутствие потерь закомиченных изменений
2. Оценка производительности и масштабируемости под нагрузкой (что-то в архетектуре подсказывает, что масштабируемости не будет)
29 авг 11, 15:23    [11195566]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Dimitry Sibiryakov
Возьмём тысячу клиентов, желающих одновременно отправить свои изменения на сервер. Пусть
одна отправка занимает одну секунду. Тысячный клиент будет ждать 999 секунд пока сервер
обработает пакеты остальных. Разве нет?

Ммм... хороший вопрос. Уточню у разработчика как это на практике происходит. Но вообще конечно на 1000 одновременных пользователей такая архитектура не рассчитана, это я и сама понимаю. До сотни - да, наверно. Больше - вряд-ли. Тут уже реально распределенную БД нужно делать, чтобы именно в такой архитектуре играться. И при этом далеко не факт что игра будет стоить свеч.

Dimitry Sibiryakov
Как "увидит"? Перечитав из файла каждую транзакцию после седьмой? А если их успело пройти
сто тысяч?..

По индексам. Данные же приходят на обновление конкретной записи, а у нее есть ключ. ищем по ключу в индексе, смотрим, транзакция с каким номером совершила последнее обновление. Где-то так. Если интересны более конкретные детали - это я уточню у разработчика.
29 авг 11, 15:29    [11195621]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Dimitry Sibiryakov
Member

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

интересующаяся_мнением
Ну а как вы в обычной базе определяете, что это уже существующая запись? По ключу. А поиск
- индексы.

В обычной базе нет Вашей главной фишки - строго последовательного доступа. Поэтому всегда
можно сразу (двумя чтениями для IB/FB, одним для Oracle) найти последнюю версию нужной
записи и сравнить номер создавшей её транзакции с требуемым.

А теперь расскажите поподробнее об индексах: как устроены, когда и как обновляются, где
лежат
.

Posted via ActualForum NNTP Server 1.4

29 авг 11, 15:55    [11195876]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Gluk (Kazan)
интересующаяся_мнением
Поэтому и хочу коллективного мнения и критики подхода. :)
Только аргументированной.


1. Распишите, что происходит когда падает сервер и как обеспечивается отсутствие потерь закомиченных изменений
2. Оценка производительности и масштабируемости под нагрузкой (что-то в архетектуре подсказывает, что масштабируемости не будет)

1. Ммм... Если сервер упал так, что данные забрать можно, берем файл базы копируем ее на другую машину и говорим что она у нас теперь сервер. Если так, что порушились и данные в том числе - да, потери закоммиченных транзакций будут, но только самых последних. В этом случае, смотрим на какой из клиентских машин самый большой номер транзакции и объявляем ее сервером. Последние данные придется перевбить.
2. Эхх... сама пытаюсь стрясти эти данные с разработчиков :) Смотря что считать масштабируемостью. Рост числа одновременно работающих пользователей? Добавляются они довольно легко, макс. кол-во, я думаю, будет сильно зависеть от задач системы. Если она массово обновляет, - лимит кончится быстрее, по моим ощущениям - не больше сотни. Но, - не проверяла и, - очень хочу проверить. Если в основном только читает, а обновляет редко, - не вижу никаких причин, почему их не может быть больше.
Рост объема базы? Здесь да, машины у нас клиентские обычные, террабайтные базы ты на них не запихнешь :) Но некоторое кол-во гигов - почему бы и нет? При том что их практика показывает - что для учетных задач бухгалтерии у них прирост на практике небольшой - около 200МБ в год на предприятие из 2000 человек.

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

В таких задачах важны не кол-во одновременно работающих пользователей и масштабируемость.. и даже ни спасение последних закоммиченных транзакций - они последний документ ручками вобьют если что. Им гораздо важнее иметь возможность чтобы у них автоматом считались многие вещи по весьма извращенным формулам, учитывающим массу дополнительных параметров. Часто таких, что в них черт ногу сломит. Ну и чтобы расширить/поменять все это было можно легко если вдруг правила изменятся или новые требования выйдут.
И еще момент: далеко не каждый магазин средней паршивости может позволить себе даже SQL Server, не говоря уж об Oracle... Есть и еще один момент: у нас сейчас направление партии и правительства - уход с Win в госучреждениях. Это решение вроде как в теории может пойти на чем угодно. Максимум - небольшой допил потребуется на особенности компиллятора C++.

Вообще - по-моим ощущениям - из этого можно сделать эдакий проапгрейженный мультиплатформенный Access. С многопользовательностью у него будет попроще чем у Access, ну и язык фреймворка, как я понимаю, побогаче. А ограничения на масштабируемость именно БД - примерно те же.
29 авг 11, 15:56    [11195882]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Yo.!
Guest
интересующаяся_мнением
Может, но, во-первых это критично только в случаях конфликта на обновление. Если идет массовая вставка данных - какая разница в каком порядке они вставятся? А при конфликте обновления - см. чуть выше, как эту ситуацию можно минимизировать.

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

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

как раз тут без всяких проблем, блокировочник поставит лок и насильно серилизует транзакции, а версионник скорее всего применит патерн оптимистичной блокировки и тоже гарантированно избежит записи мусора в бд.
29 авг 11, 15:58    [11195906]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Dimitry Sibiryakov
Member

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

интересующаяся_мнением
И еще момент: далеко не каждый магазин средней паршивости может позволить себе даже SQL
Server, не говоря уж об Oracle...

Т.е. о бесплатных СУБД у вас там не слышали вообще...

Posted via ActualForum NNTP Server 1.4

29 авг 11, 15:59    [11195920]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Yo.!
Guest
интересующаяся_мнением
И еще момент: далеко не каждый магазин средней паршивости может позволить себе даже SQL Server, не говоря уж об Oracle...

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

Сообщение было отредактировано: 29 авг 11, 17:20
29 авг 11, 16:06    [11195978]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

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


В таком случае пугают задекларированные полтора землекопа 2.5 разработчика
Ну и нишевость:

1. Убедить 1C пользоваться этим вряд-ли удастся
2. Написать что-то таким ресурсом конкурирующее с 1C на его же поле - нереально
29 авг 11, 16:06    [11195981]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
интересующаяся_мнением
Dimitry Sibiryakov
Возьмём тысячу клиентов, желающих одновременно отправить свои изменения на сервер. Пусть
одна отправка занимает одну секунду. Тысячный клиент будет ждать 999 секунд пока сервер
обработает пакеты остальных. Разве нет?

Ммм... хороший вопрос. Уточню у разработчика как это на практике происходит. Но вообще конечно на 1000 одновременных пользователей такая архитектура не рассчитана, это я и сама понимаю. До сотни - да, наверно. Больше - вряд-ли. Тут уже реально распределенную БД нужно делать, чтобы именно в такой архитектуре играться. И при этом далеко не факт что игра будет стоить свеч.

Обсудила, уточнила. Да, клиент будет ждать ответа с сервера. Но это не помешает ему заниматься другими задачами параллельно. В других окнах, - а ожидание будет происходить только в одном окне.
В ответ на это обсуждение у меня тоже возник вопрос: а как с этим в реляционных базах? Смотрите, - вроде бы да - в Викте все пишется в конец общего файла, - все вынуждены ждать. В классической РСУБД вы в теории можете открывать несколько параллельных транзакций и писать в разные таблицы, расположенные в разных местах. Но лог транзакций то общий, соответственно на запись в него - очередь. И на диск вам тоже писать все это тоже придется, а в разные места еще и медленней получится, - если у вас один диск и один процессор, потому что головка скачет, чтобы в разные места писать. Или я чего-то не понимаю?
29 авг 11, 16:46    [11196280]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Dimitry Sibiryakov
Member

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

интересующаяся_мнением
Но лог транзакций то общий

Это для тех СУБД у кого лог транзакций есть. Ну и как Вы сами сказали: это не мешает
серверу заниматься другими задачами параллельно.

Posted via ActualForum NNTP Server 1.4

29 авг 11, 16:51    [11196306]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Dimitry Sibiryakov
интересующаяся_мнением
Ну а как вы в обычной базе определяете, что это уже существующая запись? По ключу. А поиск
- индексы.

В обычной базе нет Вашей главной фишки - строго последовательного доступа. Поэтому всегда
можно сразу (двумя чтениями для IB/FB, одним для Oracle) найти последнюю версию нужной
записи и сравнить номер создавшей её транзакции с требуемым.

А теперь расскажите поподробнее об индексах: как устроены, когда и как обновляются, где
лежат
.

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

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

У меня ответный вопрос про "одним чтением". А физически - это как? К примеру - вот у вас таблица в сотню тысяч записей. Откуда вы вот так вот сразу узнаете в каком месте таблицы находится искомая запись?
29 авг 11, 16:58    [11196359]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
интересующаяся_мнением
И на диск вам тоже писать все это тоже придется, а в разные места еще и медленней получится, - если у вас один диск и один процессор, потому что головка скачет, чтобы в разные места писать. Или я чего-то не понимаю?


не понимаете. REDO (или лог транзакций) обычно на отдельном девайсе.
Не надо головке дергаться
29 авг 11, 17:05    [11196415]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Yo.!
минимизировать без шансов, на практике это будет выглядеть как еженедельные продажи товара больше чем реально на складе. просто потому, что винда чуть проглючила или нетворк чей-то вирус забил на какое-то время. помниться у фокспро это выливалась в поломанные индексы еженедельно.

Не совсем понимаю - почему. Можно поподробнее? Как можно продать товара больше чем на складе если остаток контролирует сервер и просто не даст это сделать?

Yo.!
еще интересно, что происходит если перегрузить клиента когда он уже записал транзакцию локально, но еще не передал эту транзакцию на "централь".

Дык клиент не имеет права записать транзакцию. Он может только попросить сервер записать ему транзакцию. Я же писала - транзакционность контролирует сервер и только он.

Yo.!
интересующаяся_мнением
Вы подумайте еще вот о чем: если у вас клиент-сервер классический, вы вообще не сможете отследить такую ситуацию с конфликтом обновления. Сервер просто перезапишет данные поверх и все. Разве нет?

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

Стоп стоп. Блокировочник поставит лок, только если он знает, что две операционистки открыли на редактирование общий документ. Как вы хотите обеспечить это знание? Открыть транзакцию на клиенте и ждать пока операционистка закончит? А если она чай уйдет пить?
Насчет версионника - кто-то тут писал, что то, что сделано в этой БД и есть оптимистические блокировки.
29 авг 11, 17:11    [11196458]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Gluk (Kazan)
интересующаяся_мнением
И на диск вам тоже писать все это тоже придется, а в разные места еще и медленней получится, - если у вас один диск и один процессор, потому что головка скачет, чтобы в разные места писать. Или я чего-то не понимаю?


не понимаете. REDO (или лог транзакций) обычно на отдельном девайсе.
Не надо головке дергаться

Ок, давайте с отдельным девайсом. Но при этом:
1. Это никак не изменит того факта, что сама процедура записи в этот конкретно лог, лежащий на одном девайсе для 1000 пользователей, пожелавших одновременно совершить какие-то операции, должна происходить последовательно.
... вот тут сказали что есть системы без лога транзакций. Мне как-то все время приходилось сталкиваться только с теми что лог ведут... интересно как в таких системах этот момент организован.

2. Допустим у вас транзакция обновляет две разные таблицы и соотв. обновляется лог транзакций. Данные - на одном девайсе, лог - на другом. Получается что вам нужно: сделать две записи в лог, и здесь головка не дернулась. Сделать две записи в два разных файла и здесь головка дергается. В целом - три операции записи. В Викте отдельного лога нет, - только файл данных. Соответственно имеем на это же всего две записи без дерганий головки.
29 авг 11, 17:18    [11196531]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Dimitry Sibiryakov
интересующаяся_мнением
Но лог транзакций то общий

Это для тех СУБД у кого лог транзакций есть. Ну и как Вы сами сказали: это не мешает
серверу заниматься другими задачами параллельно.

А можно поподробнее? Это как без лога транзакционную целостность контролировать?
Что касается параллельно - в данном случае серверу больше нечем заниматься. Чтение же только на клиентах.
29 авг 11, 17:20    [11196544]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
интересующаяся_мнением
Gluk (Kazan)
пропущено...


не понимаете. REDO (или лог транзакций) обычно на отдельном девайсе.
Не надо головке дергаться

Ок, давайте с отдельным девайсом. Но при этом:
1. Это никак не изменит того факта, что сама процедура записи в этот конкретно лог, лежащий на одном девайсе для 1000 пользователей, пожелавших одновременно совершить какие-то операции, должна происходить последовательно.
... вот тут сказали что есть системы без лога транзакций. Мне как-то все время приходилось сталкиваться только с теми что лог ведут... интересно как в таких системах этот момент организован.

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


1. Да, commit-ы сериализуются, но файл пишется последовательно, что значительно быстрее рандомной записи
2. Файлы данных обновляются в фоновом режиме, эта запись НЕ сериализуется

3. Да, есть РСУБД без логов транзакций IB и его клоны. Там сам файл данных по сути лог
29 авг 11, 17:24    [11196575]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Dimitry Sibiryakov
Member

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

интересующаяся_мнением
По размерам - файл индекса на практике примерно равен файлу данных.

Если он лежит на том же диске, то при получении транзакции сервер должен:
1) записать её в основной файл
2) записать ссылки на неё в файл индексов по числу индексов, определённых для данного типа
записи.

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

интересующаяся_мнением
У меня ответный вопрос про "одним чтением". А физически - это
как? К примеру - вот у вас таблица в сотню тысяч записей. Откуда вы вот так вот сразу
узнаете в каком месте таблицы находится искомая запись?

Если известен идентификатор записи (db_key, rowid), то он включает в себя адрес страницы
на которой она лежит. Если идентификатор неизвестен, тогда как обычно - требуется
пробежаться по индексу для его получения. После чего - читается нужная страница. Никаких
отличий от Вашей схемы, не считая выровненности страниц по кластерам/секторам диска, что
ускоряет их чтение.

Posted via ActualForum NNTP Server 1.4

29 авг 11, 17:26    [11196597]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Dimitry Sibiryakov
Member

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

интересующаяся_мнением
Это как без лога транзакционную целостность контролировать?

А какое отношение имеет лог к целостности?

А так легко: достаточно менять статус транзакции на "закоммичено" только после сброса на
диск её грязных страниц. А точнее - держать Transaction Invention Page последней в очереди
на запись.

Posted via ActualForum NNTP Server 1.4

29 авг 11, 17:32    [11196658]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
.ЛП
Guest
2 интересующаяся_мнением
интересующаяся_мнением
.ЛП
Этот вопрос очень, очень интересен.
Особенно в свете декларируемого "в случае потери сервера, сервером можно объявить любую из рабочих станций"

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

Ещё раз. По буквам. Медленно.
Станция пропустила какое-то обновление.
Был поток транзакций от других машин, транзакции номер 1, 2, 3, 4, 5.
Бухгалтер порнуху смотрел, чем загрузил всю свою машину, и проспал бродкаст. До станции дошли транзакции 1, 2, 3, 4.
В этот момент "сервер" умер.
Как станция узнает о том, что она чего то недополучила? У кого она это узнает? У "сервера"? Но ведь "сервер" - умер.

Если она об этом не узнает - кто помешает именно эту станцию сделать новым "сервером" взамен умершего?
Пришёл админ, "просто выбирается какая-нибудь станция (ручками, не автоматом) и у нее взводится флажек. И можно жить дальше.".
Не будет же он шерстить все рабочие станции на предмет полного соответствия ихних локальных данных.

Если эту больную станцию сделают сервером - какие номера она будет выдавать для новых транзакций? Следующий номер будет 5? Что произойдёт на всех остальных рабочих станциях, когда к ним второй раз придёт транзакция за номером 5, причём совсем другая, не та, что в первый раз?

интересующаяся_мнением
.ЛП
В базе хранится вся история, от ишачьей пасхи до сегодняшнего дня. Вся эта база в полном объёме находится у всех клиентов.

На самом деле, не совсем так. У них там есть механизм - называется компрессирование. Он как раз и предназначен для того, чтобы "схлопнуть" историю.

Т.е. статейные заявления о том, что в любой момент времени можно получить состояние базы на любой момент времени - не соответствуют действительности.
Правильно я понимаю?

интересующаяся_мнением
Не клиент бродкастит, а сервер. Клиент передает данные на сервер уже не бродкастом а конкретно ему. И не на каждый чих. Данные передаются только об изменениях.

Это неважно, рассылает бродкастовый пакет сам клиент, или псевдо-сервер по требованию клиента. Важдно, что по требованию клиента. Как только клиент что-то проапдейтил, так тут же все остальные клиенты вынуждены ловить и обрабатывать бродкаст об этом апдейте.

интересующаяся_мнением
А что вы имеете в виду под "нужно, не нужно, пофигу?"

Именно это и имею в виду.
Рабочая станция создала одну запись. Никому не нужную, кроме неё. Остальные про эту запись и знать не знали бы, и не нужно им оно.
А потом эта одна запись этой самой рабочей станцией начинает непрерывно апдейтиться. С частотой стопиццоттыщщ апдейтов в секунду.
Чем в это время будут заниматься остальные рабочие станции? Ловить из сети бродкасты и обрабатывать их? Стопиццоттыщщ бродкастов в секунду, по поводу апдейта записи, которая нафиг им не нужна?
В статье содержатся какие-то умные слова насчёт горизонтальной маштабируемости, но это, знаете ли, маштабируемость наоборот. Каждый новый (пишущий) клиент понижает общую производительность системы (как читателей, так и писателей).

интересующаяся_мнением
Ммм.. да. Скорее всего. Так и не позиционируется это для больших нагрузок на запись.

Тогда зачем использовать способ хранения в виде append-only лога изменений?

интересующаяся_мнением
У Аксес я так понимаю все-таки проблемы с многопользовательностью? Или нет?

Конечно.
Но в обсуждаемой системе их еще больше :)
По крайней мере, если аксесовский клиент сойдёт с ума, и начнёт стопиццоттыщ раз в секунду апдейтить запись - он разве что сеть подзасрёт. У вас же оно подзасрёт и процессорные мощности всех остальных клиентов.

интересующаяся_мнением
.ЛП
Даже на де-факто умершем файл-серверном нечте.

А вот с этим я кстати не согласна. Тот же Access используется очень широко.

Какая разница, насколько широко он используется, если этот продукт не развивается? Последние значимые нововведения были в 2000-ом году (поддержка клиент-серверного режима в виде adp-клиента к базе MS SQL Server). После этого аксес умер. С тех пор нововведения от версии к версии - нечто из серии "у трупа какое-то время продолжают расти волосы и ногти".
Впрочем, неважно.

интересующаяся_мнением
И как раз для случаев когда в офисе нужно быстро сваять что-то учетное очень малыми силами и при почти полном отсутствии знаний/образования/ресурсов...
.... Вот поэтому и "не сделать на нормальной СУБД".

Используйте LightSwitch.
Кривая вхождения как у аксеса. Но по крайней мере СУБД нормальная, а не mdb. И не "Викта".
29 авг 11, 17:37    [11196705]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Dimitry Sibiryakov
Member

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

.ЛП
Не будет же он шерстить все рабочие станции на предмет полного соответствия ихних
локальных данных.

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

Posted via ActualForum NNTP Server 1.4

29 авг 11, 17:44    [11196790]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8 9 10 .. 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить