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

Откуда: Днепропетровск
Сообщений: 1929
SergSuper
не важно что я считаю, важно что я вижу
а я вижу что например многие банки, и большие и маленькие, переходят на работу на одной железяке - сервер стоит в Москве, а филиалы разбросаны по всей стране, в маленьких и больших городах
года три назад еще не все решались, а сейчас это приобрело массовый характер

Неплохо было бы увидеть статистику, сколько банков и сколько своих филиалов эксплуатируют чисто в терминальном режиме, а сколько нет.
Сильно сомневаюсь насчет 'приобрело массовый характер'. Ну да банки, они такие банки что все может быть.
SergSuper
а что - у Вас и правда стоит генератор, готовый автоматически включится в сеть? ну вот не верю, в лучшем случае юпс, который час -другой продержит, если его еще периодически проверяют


У нас генератора нет. Я занимаюсь тиражируемым софтом. Света нет, мы пишем пулю.
A вот у одного нашего клиента магазин недавно на день обесточили, он привез генератор из офиса, и дневная выручка была получена им почти в полном объеме. Ну а что, некому московскому банку прибыль его одного филиала за день не нужна в такой ситуации? Вот так прям во внутренней инструкции и написано, если канал связи не работает, клиентов не обслуживаем?

И еще, по поводу генераторов, мне кажется не корректным Ваше сопоставление проблем надежности электросетей и сетей передачи данных. Пока отличия на порядок.
14 окт 11, 12:45    [11440287]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
artemana
SergSuper
не важно что я считаю, важно что я вижу
а я вижу что например многие банки, и большие и маленькие, переходят на работу на одной железяке - сервер стоит в Москве, а филиалы разбросаны по всей стране, в маленьких и больших городах
года три назад еще не все решались, а сейчас это приобрело массовый характер

Неплохо было бы увидеть статистику, сколько банков и сколько своих филиалов эксплуатируют чисто в терминальном режиме, а сколько нет.
Сильно сомневаюсь насчет 'приобрело массовый характер'. Ну да банки, они такие банки что все может быть.
я сужу по своему опыту
за последние пару лет имел дело с 10 банками, 5 из них в первой двадцатке(или около)
только один из них сейчас работает на разных железяках с филиалами, один в процессе перевода, один перешел недавно
из них в терминальном режиме работает точно 4 банка, 2 нетерминально, про остальные не знаю
artemana
SergSuper
а что - у Вас и правда стоит генератор, готовый автоматически включится в сеть? ну вот не верю, в лучшем случае юпс, который час -другой продержит, если его еще периодически проверяют


У нас генератора нет. Я занимаюсь тиражируемым софтом. Света нет, мы пишем пулю.
A вот у одного нашего клиента магазин недавно на день обесточили, он привез генератор из офиса, и дневная выручка была получена им почти в полном объеме. Ну а что, некому московскому банку прибыль его одного филиала за день не нужна в такой ситуации? Вот так прям во внутренней инструкции и написано, если канал связи не работает, клиентов не обслуживаем?

И еще, по поводу генераторов, мне кажется не корректным Ваше сопоставление проблем надежности электросетей и сетей передачи данных. Пока отличия на порядок.

я не знаю что у них в инструкции, но наверное заключают договоры с двумя независимыми провайдерами, есть GRPS на худой конец
ну вот не боятся как-то
14 окт 11, 14:18    [11441161]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
--------------------------------
Guest
Действительно есть такая тенденция у банков, но она, вобщем-то, ничего не доказывает,
кроме того, что банки тормоза консервативны.
Ведь есть и обратная тенденция в мире - создание системы из множества дешевых машин,
а банки все еще идут в направлении создания системы на одной могучей машине.
19 окт 11, 10:29    [11464200]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
vadiminfo
Member

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

Т.е. "ни на что не похожая БД" на самом деле находится в в русле "создание системы из множества дешевых машин"? Стало быть быть, если она и "не похожа", то не в силу оригинальности идей. А так ить полно файл серверных БДна убитых компах, которые качали БД на кажный комп, ввиду крайней ненадежности компов. Например, на Аксцессе это сделать могет кажный даже не заметив, что тут есть какая-то не похожая ни на что идея.
Возможно, она не похожа на современные достижантия, а на морально устаревшие или не имещие рациональное зерно еще как похожа?
Возможно, следует все же переформулировать, с целью уточнения: "Ни на что современное не похожая БД (хотя в прошлом веке похожая на кое-что эдакое)" ?
20 окт 11, 08:54    [11470189]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
RXL
Member

Откуда:
Сообщений: 1599
vadiminfo,

Но разве опыт Гугля не доказывает, что в истинно кластерных условиях и с несколькими датацентрами использование дешевого железа оправдано и выходит много выгоднее? Условия, конечно, специфичные.
20 окт 11, 12:27    [11471775]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
RXL
vadiminfo,

Но разве опыт Гугля не доказывает, что в истинно кластерных условиях и с несколькими датацентрами использование дешевого железа оправдано и выходит много выгоднее? Условия, конечно, специфичные.

Так Вы хотите сказать, что не на что не похожая БД похожа на Гугль? А клиенты с БД ни на что не похожей БД на "истинно кластерных условиях и с несколькими датацентрами".
"Дешевые железо Гугля" - это 286-е? Мож у них тацентры на комапах в нескока милионов баксов?
20 окт 11, 21:26    [11475537]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
FinSoft
Member

Откуда:
Сообщений: 66
artemana
SergSuper
пропущено...
нет, не альтернативным
всё именно идет к тому что будет либо вэб-интерфейс, либо терминал

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

Зачастую тормозит. Уравниловка. Мощности локальных машин есть, но не используются.

На каком сервере под терминал могут тормозить 10-15 пользователей? У одного клиента когда-то такое наблюдал на одноядерном атлоне с 512мб озу. Но такое железо снято с производства лет 6 назад. Локальных машин может и не быть. Попробуйте поставить терминальные станции. Они хоть и не дешевле обычных компьютеров, зато имеют немало преимуществ. Например, вместо гудящего ящика под ногами куда приятнее моник на небольшой подставке и тишина, аж противно становится. Срок службы в 2 раза больше, потребление электричества значительно ниже, не требует настройки и инсталяции какого-либо софта (только строчка коннекта к серверу). В чем сейчас основная проблема использования компьютеров с точки зрения обычного пользователя? Их сложность. Даже специалисты зачастую не понимают, что происходит внутрях работающего софта. Поэтому и надеются вынести вычисления в "облака", предложив юзерам снять головную боль с установленным локально софтом.
А почему как аксиома воспринимается, что локальная работа на множестве отдельных машин будет быстрее, чем на терминальном сервере? Простой пример. Делает юзер оборотку по товарам за три последние месяца. Что произойдет? Данные будут считываться с жесткого диска. На терминале достаточно одному пользователю выполнить эту операцию, все остальные будут дергать информацию уже не с диска, а из общего кэша в оперативной памяти, что в несколько раз быстрее. Переполнится кэш? А какой размер баз данных у большинства бизнес-пользователей и сколько оперативки можно (недорого) поставить на сервер?
Другой пример. Сформировал юзер отчет. Через пару минут другой хочет тот-же отчет с теми-же параметрами. Почему бы ему не предложить взять готовый у первого? И не тратить время на новый расчет?
Еще пример. Предположим, что есть некий открытый период, в который вносятся изменения. Затем решили, что можно его сократить. Закрываем более поздней датой. В закрытом периоде сохраняем готовые результаты для наиболее восстребованных запросов. У всех пользователей на терминале скорость построения отчетов по данным закрываемого периода взлетает на порядок.
Я прекрасно понимаю, что есть некая система, успешно внедренная у многих пользователей. Выработались определенный стиль мышления, определенные стандарты. Но важно не только сохранять сделанные инвестиции, но и смотреть, как приспособить имеющуюся технологию к новым реалиям. Почему не попробывать с приемлемыми затратами приспособить имеющийся софт к работе на терминальных серверах? Тем более, если как у Викты, используется файловая база. Это же не переписывать весь софт в клиент-сервер или web. Пусть в этой системе логическим пользователем будет терминальный сервер, а распределение нагрузок перенесем на несколько серверов, как в старой системе. Тогда и пользователей можно подключить на 1-2 порядка больше, а это уже горизонты для старой системы...
21 окт 11, 21:33    [11481819]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
mayton
Member

Откуда: loopback
Сообщений: 53430
+1. Здесь в принципе пережёвывается идея просто о грамотном переписывании
задачи с материализацией нужных аналитических данных и построением
cubes.
21 окт 11, 23:31    [11482243]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
RXL
Member

Откуда:
Сообщений: 1599
vadiminfo
RXL
vadiminfo,

Но разве опыт Гугля не доказывает, что в истинно кластерных условиях и с несколькими датацентрами использование дешевого железа оправдано и выходит много выгоднее? Условия, конечно, специфичные.

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


Если вы внимательно меня прочитали, то должны были заметить, что, во-первых, я ничего про базу не говорил, а, во-вторых, про 286-е ПК тоже не говорил. Чем гадать - почитайте в сети. Вкратце: они используют современные мамки и диски офисно-бытового уровня. Срок работы такого оборудования до списания - два года. По производительности оно (кроме дисков) не уступает серверному железу, зато в несколько раз дешевле и, за счет регулярного обновления, поддерживается на современном уровне производительности.
22 окт 11, 14:01    [11483116]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
FinSoft
А почему как аксиома воспринимается, что локальная работа на множестве отдельных машин будет быстрее, чем на терминальном сервере?

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

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

Возьмем, к примеру, любое среднее производственное предприятие с численностью сотрудников около 1500. При хорошем уровне автоматизации, ERP система должна насчитывать ну никак не меньше 100 рабочих мест. Заметим, речь идет об одной, единой системе, а значит все хранится в одной центральной БД. Заметим так же, что такие системы хоть и не работают с гипертрофированно большими объемами данных, например характерными для билинговых систем, разместить все базу в оперативной памяти сервера не выйдет. Но это еще пол беды. Информационная модель современной ERP-системы чрезвычайно сложна, а значит, в ней есть много таблиц (=>10^3) и связей между ними. Основных причины две - сложность предметной области и притязания на универсальность решения. В такой системе неизбежно возникают массовые одновременные чтения, так как она призвана решить широкий круг относительно независимых подзадач. Работа складского хозяйства не особо связанна с работой ОТиЗ, или работа одного склада с работой другого. Всем и часто от системы что то надо, кому то надо что то ввести, кому то надо что то посмотреть. Причем ввод, это же непросто импорт с какого то источника, он неизбежно сопровождается чтением. Вводим счет на продажу, читаем словари - товары, валюты, курсы, контрагенты, прайсы, читаем и анализируем правила бизнес логики и прочее и прочее и прочее. А если учесть возрастание потребностей пользователей в интервалах подготовки периодической отчетности, то как можно говорить об отсутствии массовых, различных и одновременных читающих обработок (сложных и простых)? Может быть не надо было строить такой большой завод?

Нам в GrossBee, как и разработчикам Викты, использование свободных мощностей рабочих станций, кажется разумным решением. Есть ли другие варианты решений? Да! И среди них тьма вполне успешных работающих!! А зачастую ни какая локальная копия данных под некую задачу и не нужна!!! Но при прочих равных условиях, ERP системы с локальными усеченными копиями БД, могут работать и работают быстрее.
22 окт 11, 18:47    [11483520]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
FinSoft
Member

Откуда:
Сообщений: 66
artemana
FinSoft
А почему как аксиома воспринимается, что локальная работа на множестве отдельных машин будет быстрее, чем на терминальном сервере?

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

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

Возьмем, к примеру, любое среднее производственное предприятие с численностью сотрудников около 1500. При хорошем уровне автоматизации, ERP система должна насчитывать ну никак не меньше 100 рабочих мест. Заметим, речь идет об одной, единой системе, а значит все хранится в одной центральной БД. Заметим так же, что такие системы хоть и не работают с гипертрофированно большими объемами данных, например характерными для билинговых систем, разместить все базу в оперативной памяти сервера не выйдет. Но это еще пол беды. Информационная модель современной ERP-системы чрезвычайно сложна, а значит, в ней есть много таблиц (=>10^3) и связей между ними. Основных причины две - сложность предметной области и притязания на универсальность решения. В такой системе неизбежно возникают массовые одновременные чтения, так как она призвана решить широкий круг относительно независимых подзадач. Работа складского хозяйства не особо связанна с работой ОТиЗ, или работа одного склада с работой другого. Всем и часто от системы что то надо, кому то надо что то ввести, кому то надо что то посмотреть. Причем ввод, это же непросто импорт с какого то источника, он неизбежно сопровождается чтением. Вводим счет на продажу, читаем словари - товары, валюты, курсы, контрагенты, прайсы, читаем и анализируем правила бизнес логики и прочее и прочее и прочее. А если учесть возрастание потребностей пользователей в интервалах подготовки периодической отчетности, то как можно говорить об отсутствии массовых, различных и одновременных читающих обработок (сложных и простых)? Может быть не надо было строить такой большой завод?

Нам в GrossBee, как и разработчикам Викты, использование свободных мощностей рабочих станций, кажется разумным решением. Есть ли другие варианты решений? Да! И среди них тьма вполне успешных работающих!! А зачастую ни какая локальная копия данных под некую задачу и не нужна!!! Но при прочих равных условиях, ERP системы с локальными усеченными копиями БД, могут работать и работают быстрее.

В данной теме изначально писали о гораздо более скромном количестве пользователей. Для 100 может, конечно, одного терминального сервера и не хватить, зависит от сложности выполняемых задач. Но все равно я не поверю, что работа на 100 отдельных машинах будет эффективнее, чем работа на 2-3 терминальных серверах.
Все еще сильно зависит от прикладного приложения. Например, мне сложно представить, о каких объемах информации, не помещающихся в ОЗУ, идет речь. Когда-то прикидывал, если 200 накладных в день, то за год это ~50-60мб в таблице шапок, в пределах 200-300мб в строках (для торговых контор, для производства последняя цифра должна быть существенно меньше). Пусть будет больше 200 накладных, в базе все равно редко имеет смысл держать более 3-4 лет. И в ОЗУ грузить старые данные далеко не всегда надо, чаще можно оперировать готовыми итогами. Чтения же всяких значений и бизнес-правил из номенклаторов на терминальных серверах происходит так-же быстро, как при локальной работе - сотые доли секунды для файловых баз.
Могу предположить, что архитектура используемой системы такова, что для универсальности все операции своливаются в одну-две огромные таблицы. Количество таблиц более 1000 тоже наводит на вопросы. Это же не САП с огромной историей развития. Можно делать и комбинированные таблицы (например, шапки складских документов или производственных документов, их же строки и т.п.), тогда количество будет значительно меньше.
22 окт 11, 20:26    [11483696]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
artemana
Но при прочих равных условиях, ERP системы с локальными усеченными копиями БД, могут работать и работают быстрее.
да скорость далеко не самое главное
надо увеличить скорость - поменял железяку и всего делов

а вот такой вопрос заинтересовал: где у вас функционал лежит?
23 окт 11, 01:08    [11484384]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4809
artemana
притязания на универсальность решения.
в этом, имхо, и есть главная проблема "современных ERP-систем". Решение любой конкретной задачи всегда будет оптимальней, чем универсальное решение на все случаи жизни, отсюда и все проблемы с производительностью, которые некоторые решают такими странными и "ни на что не похожими" способами
23 окт 11, 01:12    [11484391]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
RXL
Если вы внимательно меня прочитали, то должны были заметить, что, во-первых, я ничего про базу не говорил, а, во-вторых, про 286-е ПК тоже не говорил. Чем гадать - почитайте в сети. Вкратце: они используют современные мамки и диски офисно-бытового уровня. Срок работы такого оборудования до списания - два года. По производительности оно (кроме дисков) не уступает серверному железу, зато в несколько раз дешевле и, за счет регулярного обновления, поддерживается на современном уровне производительности.


Если Вы про базу ничего не говорили, то к чему Вы про Гугл то начали?
Я то говорил исключительно про распределенную по клиентам БД: основную якобы идею "ни на что не похожей БД". Не про кластеры и дата центры, а про БД распределенной на КЛИЕНТы.
Или Вы настаиваете, что она похjжа на Гугл?. Т.е. Гугл на клиентов, к примеру, мне на комп всю БД тасчит, шобы я быстрей читал?
Или при чем тут он вообще?
23 окт 11, 01:59    [11484444]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
SergSuper
artemana
Но при прочих равных условиях, ERP системы с локальными усеченными копиями БД, могут работать и работают быстрее.
да скорость далеко не самое главное
надо увеличить скорость - поменял железяку и всего делов


Во во, или можно бизнес сменить, если денег не хватит. Подумаешь проблема - скорость какая то.
Шутки шутками, но я бы отчасти согласился бы с Вами (только директору излагать будете Вы), если бы мы не были в контексте "Дискуссии о преимуществах и недостатках различных СУБД."
SergSuper
а вот такой вопрос заинтересовал: где у вас функционал лежит?

И там и там.
В базе данных большинство кода занято формированием хранимых агрегатов. Кода в базе много - объем скрипов мегабайты, но клиент еще больше!
Хотя в БД есть приличный набор процедур для различных отложенных расчетов и отчетов, все таки основная часть этих задач реализована на клиенте. Относительная скудность PSQL тому основная причина.
23 окт 11, 13:16    [11484818]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Shlippenbaranus
Member

Откуда:
Сообщений: 241
SergSuper
не важно что я считаю, важно что я вижу
а я вижу что например многие банки, и большие и маленькие, переходят на работу на одной железяке - сервер стоит в Москве, а филиалы разбросаны по всей стране, в маленьких и больших городах
года три назад еще не все решались, а сейчас это приобрело массовый характер


Да-да, "миллионы домохозяек не могут ошибаться".

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

А вообще, интересно, чем дело закончилось - дали им денег на доработку? /* :) */
22 окт 12, 14:01    [13356537]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Shlippenbaranus
Member

Откуда:
Сообщений: 241
Shlippenbaranus
А вообще, интересно, чем дело закончилось - дали им денег на доработку?


"Им" - оразработчикам СУБД "Викта", естественно. Жаль, топикстартер ушел.
22 окт 12, 14:09    [13356603]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
ПК "СП-Z50", о котором идет речь, выдвигался на конкурс в Агентство стратегических инициатив" (www.asi.ru). Там было достаточно подробное обсуждение - на мои вопросы отвечала (вероятно) Тамара Потапова. Сейчас, кажется, этого проекта нет в АСИ.
22 окт 12, 14:54    [13356954]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Shlippenbaranus
SergSuper
не важно что я считаю, важно что я вижу
а я вижу что например многие банки, и большие и маленькие, переходят на работу на одной железяке - сервер стоит в Москве, а филиалы разбросаны по всей стране, в маленьких и больших городах
года три назад еще не все решались, а сейчас это приобрело массовый характер


Да-да, "миллионы домохозяек не могут ошибаться".

По поводу сервера в Москве - слышал [из первых рук] историю о том, как человек, застряв в Новосибирске, неделю не мог получить в банке деньги, поскольку из-за разницы во времени пока в Москве раскочегаривали сервера/наманикюривали ногти, в Новосибирске заканчивался рабочий день. Так и вел здоровый образ жизни - ходил через весь город пешком, питался воздухом и водкой (осталась после конференции), пока его в банк не перестали пускать. Впечатлений у него осталось на всю жизнь.
/
Неплохо так домохозяйки развлекаются.
Хотя аргумент сильный, и ведь не поспоришь!
Тоже буду использовать
22 окт 12, 17:39    [13358042]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
автор
Очень интересует ваше мнение о строении БД, особенности которой описаны вот здесь...

Если кому-то еще интересно обсуждение, исходная статья переехала сюда: Отличительные особенности БД комплекса «Викта»
9 ноя 12, 11:26    [13444730]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11593
Зря вы очередной Btrieve изобретаете. Даже в нём SQL появился. Хотя и под другим названием.
9 ноя 12, 12:42    [13445367]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Basil A. Sidorov
Зря вы очередной Btrieve изобретаете. Даже в нём SQL появился. Хотя и под другим названием.
тут больше дело в психологии, тяжело отказаться от того чем ты много лет занимался
9 ноя 12, 12:54    [13445495]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
RXL
vadiminfo
пропущено...
Так Вы хотите сказать, что не на что не похожая БД похожа на Гугль? А клиенты с БД ни на что не похожей БД на "истинно кластерных условиях и с несколькими датацентрами".
"Дешевые железо Гугля" - это 286-е? Мож у них тацентры на комапах в нескока милионов баксов?

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

Я сильно извиняюсь за вторгательное присутствие, но то, какое оборудование использует Гугль вполне можно попытаться "оценить" по фотографиям их датацентров - с дешевыми "офисно-бытовыми мамками и дисками" там как-то не особо...
9 ноя 12, 14:10    [13446389]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
SergSuper
Basil A. Sidorov
Зря вы очередной Btrieve изобретаете. Даже в нём SQL появился. Хотя и под другим названием.
тут больше дело в психологии, тяжело отказаться от того чем ты много лет занимался

Это точно. Ключевая проблема на sql.ru.
9 ноя 12, 19:07    [13448846]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 9 10 11 12 [13]
Все форумы / Сравнение СУБД Ответить