powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Проект построения большой БД - давайте пообсуждаем
25 сообщений из 307, страница 2 из 13
Проект построения большой БД - давайте пообсуждаем
    #32638677
_Dog
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DSS bez OLTP pohoze nikogda ne byvaet ;)
Po povodu VLDB: http://www.teradata.com/t/pdf.aspx?a=83673&b=117439 neplohaja ssylka.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32638706
_Dog
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoВы не в курсе почему Оракла нет в 10 меньше 1000Гб? Он не участвовал? Или участвовали не лучшие проекты? Наверное последнее.

Dumaju - price/performance budet plohim. I chem bolse TB - tem sootnosenie huze.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32638780
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ggg-Old: Кто сказал что на 32-bit нельзя поместить данных в кэш почти столько сколько и в 64-bit??? И при памяти более 4ПИ однознача 64-bit. Помоему это слегка бездоказательно.

Дорогой EugeneS как-то вы странно смотрите на тесты tpc-h???
В DSS DB2 почти везде присутствует причем не на последних позициях.

2Dog: Ты очень хорошо подумал когда написал что OLTP+DSS в одно флаконе если не смотреть на денги, то терадата????
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32638801
_Dog
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nikolay Kulikov
2Dog: Ты очень хорошо подумал когда написал что OLTP+DSS в одно флаконе если не смотреть на денги, то терадата????

Ja s IBM malo znakom. Oen' subjektivno, dumaju cto esli govorit' o DSS/OLTP v odnom flakone, to
1. TData
2. IBM.

Vopros s IBM ocen zavisit ot strany/regiona. nemalo mest, gde IBM support/presale na nule. Eto moe mnenie.
Tdata - tam gde oni ucavstvujut - molodcy. Support/presale na vysote (drugoe delo, cto mogo gde ih resenija neprohodiat po cene libo izza specificeskogo HW. ). Ne nado mne rasskazyvat, kak horoso TData krutitsia na HP-UX.

o Sybase IQ: ne pozicioniruetsia kak odin flakon (poka). Ocen prostaja, poniatnaja i bystraja baza. Problemy: Sybase predstavitel'stv - nevidno. Marketinga pocti nol'.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32638855
_Dog
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hotia, Nikolay, ty prav, esli namekaes na to cto TDATA ne pozicioniruetsia kak OLTP.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32638890
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Nikolay Kulikov:
Я не утверждал однозначно, что на 32бит системе нельзя использовать кэш более 3Гб. Естественно PAE и AWE даст такую возможность. Но если у организации терабайтная БД и нужно много ОЗУ, та зачем ограничивать себя костылями, а не взять нормальный 64бит сервер? Мне AWE чем-то напоминает DOSовские примочки XMS+EMS. Только мастштаб больше.
Вчера прочитал на сайте IBM про интел сервера, которые поддерживают hot swap память и зеркалирование памяти.
Я в обалдении. Не знал, что так можно. Жалко, что IBM не представлена нормально в Украине. :-(
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32638968
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nikolay KulikovGgg-Old: Кто сказал что на 32-bit нельзя поместить данных в кэш почти столько сколько и в 64-bit??? И при памяти более 4ПИ однознача 64-bit. Помоему это слегка бездоказательно.

Дорогой EugeneS как-то вы странно смотрите на тесты tpc-h???
В DSS DB2 почти везде присутствует причем не на последних позициях.

2Dog: Ты очень хорошо подумал когда написал что OLTP+DSS в одно флаконе если не смотреть на денги, то терадата????

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

Если с учетом кластеров , то да DB2 там присутствует, хочу так же добавить , что у IBM есть еще mainfraim, и в последних тестах и вроде ка нет.

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


Теперь про TERADATA.
Коллеги,
давайте будем реалистами.
Кто-нибудь работал с TERADATA?
На просторах бывшего CНГ есть представительство этой компании?
Кто-нибудь с ней работал?
А теперь ключевой вопрос,
Вы верите в "чудо", что малоиспользуемый продукт вдруг окажется тем что именно вам надо?

Сомневаюсь однако.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32638969
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну как же офис уже открыли.


А по поводу 32-bit и АWE. Зачем если можно без этого.
Предположим имеем машину 4 процессора 16GB памяти. Запускаем 4 Instance DB2/Informix XPS каждый instance берет свои 4GB и обслуживает свою часть БД. Без всяких AWE.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32639005
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ggg_old2 Nikolay Kulikov:
Я не утверждал однозначно, что на 32бит системе нельзя использовать кэш более 3Гб. Естественно PAE и AWE даст такую возможность. Но если у организации терабайтная БД и нужно много ОЗУ, та зачем ограничивать себя костылями, а не взять нормальный 64бит сервер? Мне AWE чем-то напоминает DOSовские примочки XMS+EMS. Только мастштаб больше.
Вчера прочитал на сайте IBM про интел сервера, которые поддерживают hot swap память и зеркалирование памяти.
Я в обалдении. Не знал, что так можно. Жалко, что IBM не представлена нормально в Украине. :-(

Да, HP тоже умеет.
На 4 проц умеет делать Mirror памяти ,а на 8 проц. RAID 5, хотя стоит это довольно прилично.
Уж HP то представлена в Украине.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32639230
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2Eugenes: Нет ты не понял. Без всяких железячных фич можно обойтись.
Каждый Instance это отдельный процесс котрый пользуется 4GB т.е вписывается в лимиты 32-bit. В тоже время они все утилизируют 16 GB в системе. Правда это получается кластер внутри одной машины.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32639315
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nikolay Kulikov2Eugenes: Нет ты не понял. Без всяких железячных фич можно обойтись.
Каждый Instance это отдельный процесс котрый пользуется 4GB т.е вписывается в лимиты 32-bit. В тоже время они все утилизируют 16 GB в системе. Правда это получается кластер внутри одной машины.

Николай, это ты про LPAR's говоришь?
Если не сложно, посоветуй техн.чтиво по HACMP c нуля.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32639332
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я тоже предлагаю вариант DB2/Informix XPS .
Только обязательно на рисковом железе.

OLTP/DSS решаются автоматом.
На одном узле сервер конфигурится под OLTP, на другом под DSS.
Таблицы видны прозрачно. Транзакции тоже общие.
Важно чтобы DSS не наступал на хвост OLTP блокировками.
Но это вопрос проектировщика, База все инструменты предоставляет.
Фрагментация поддерживается.
Архитиктура DSA при правильном проектировании приложения
отдает под одну сеcсию все ресурсы сервера, если нужно.
Прикольно смотреть как одна пользовательская сессия грузит 4 процессора на и дисковый массив 100 %.

С уважением, onstat-
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32639380
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat-

Архитиктура DSA при правильном проектировании приложения
отдает под одну сеcсию все ресурсы сервера, если нужно.
Прикольно смотреть как одна пользовательская сессия грузит 4 процессора на и дисковый массив 100 %.

С уважением, onstat-

А как это реализовано? "Одна пользовательская сессия" - это несколько процессов?
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32639495
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
killed onstat-

Архитиктура DSA при правильном проектировании приложения
отдает под одну сеcсию все ресурсы сервера, если нужно.
Прикольно смотреть как одна пользовательская сессия грузит 4 процессора на и дисковый массив 100 %.

С уважением, onstat-

А как это реализовано? "Одна пользовательская сессия" - это несколько процессов?

Да именно так. Это эсли можно так выразиться своя операционная среда
в которой для пользовательской сессии выделяются нити выполнения сервера
например одна делает join , друга group by, треться сортировку червертая подзапрос in и каждая на своем процессоре.
В двух словах не объяснишь. Поисчите на гугле Informix DSA.

С уважением, onstat-
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32639634
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А ну тогда в целом я наверное понял. В Оракле аналогичная вещь называется PQO - Parallel Query Option. Координатор процесса (сессия, инициирующая паралельную обработку) и слэйв-процессы, которые читают данные в параллель. Результаты работы слэйвов передаются координатору для получения конечного результата.

Смущает только фраза "например одна делает join , друга group by, треться сортировку червертая подзапрос in и каждая на своем процессоре".

Это же конвейер в чистом виде ;) В оракле в основном речь идет о распараллеливании ВВ. Если читаем много, есть запас по CPU и пропускной способности подсистемы ВВ, тогда есть смысл попробовать распараллелить запрос. Только это все плохо сочетается с OLTP.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32639682
andsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей ТихоновИтак, условия задачи следующие: нужно построить VLDB. Объем - терабайты.
Кто чего думает? В принципе вариантов два:

MSSQL

Oracle

Вот и давайте пообсуждаем плюсы и минусы каждого варианта ;-) .
Недавно закончил делать БД которая со временем достигнет терабайта - пока меньше. В основном DSS, плюс немного OLTP. MS SQL2k + MS AS. Пока никаких серьезных проблем нет.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32640475
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nikolay Kulikov
Ну как же офис уже открыли.
А по поводу 32-bit и АWE. Зачем если можно без этого.
Предположим имеем машину 4 процессора 16GB памяти. Запускаем 4 Instance DB2/Informix XPS каждый instance берет свои 4GB и обслуживает свою часть БД. Без всяких AWE.


А что будет, если один и тот же блок понадобиться и в том и в другом инстансе? Как там насчет Interconnect?

Informix говорите?
Это уже мертывй продукт. Я даже не считаю нужным его обсуждать.
Если вы так не считаете, то скажите зачем тогда IBM две СУБД?
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32640617
Фотография Сергей Тихонов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати, в пятницу нашел на MS-сайте очень интересный документ. На конкретном примере рассказывается про построение БД размером 10ТВ . Вот ссылка: http://www.microsoft.com/sql/techinfo/administration/2000/rosetta.asp
Кто-то может дать ссылки на подобные документы от Oracle, IBM и т.д.? Очень хочется почитать...
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32640749
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
EugeneSА что будет, если один и тот же блок понадобиться и в том и в другом инстансе? Как там насчет Interconnect?


Это shared-nothing. Координирующий агент запросит или даст указание агенту(ам) на другом на другом instance.

EugeneS
Informix говорите?
Это уже мертывй продукт. Я даже не считаю нужным его обсуждать.


Если бы он был мертвым то он не продавался и не выходили бы новые версии,
в конце года будет 9.5
Все бы мертвецы столько денег приносили....

EugeneS
Если вы так не считаете, то скажите зачем тогда IBM две СУБД?


Как сотрудник IBM могу только отослать вас к официальным документам на
http://www.software.ibm.com/data
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32640753
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот нарыл в документации:
Database Clustering Architectures: There are two primary database clustering architectures: shared-disk and shared-nothing. Shared-disk is used by Oracle RAC. DB2 for Linux employs shared-nothing.

In a shared-disk environment, each database node has its own processors but shares the disks with other nodes. Therefore all the processors can access all the disks in the cluster. This introduces additional overhead for coordinating resources and locks between nodes. For example if Node 1 wants to access data on a certain disk that has been locked for update by another node in the cluster, Node 1 must wait for other nodes to complete their operations. While this works well when there are few nodes in the cluster (e.g. mainframe environments), the overhead for distributed lock management and cache coherency issues can severely limit scalability and introduce performance degradation for 4 or more nodes, making it impractical to exploit economies of large clusters on Linux. Furthermore this approach involves specialized hardware and software for shared disk and cache management, making it a lot more expensive than shared-nothing.
Shared-nothing: As the name implies, partitions (nodes) in a shared-nothing environment do not share processors, memory or disks with partitions on other machines. Each partition acts on its own subset of data. Since each partition has its own private resources, this approach does not involve any resource contention with other servers, lending itself to virtually unlimited scalability. This is one reason DB2 for Linux can support up to 1000 partitions. And since there is no coordination overhead for accessing resources, additional machines can easily be added to the cluster with linearly scalable performance, which implies, if doubling of the data volume is matched by the doubling of the cluster resources, the high performance of the database will be maintained at the same level. If one partition in a cluster fails, its resources can dynamically be transferred to another machine, ensuring high availability. Another benefit of the shared nothing approach used by DB2 for Linux is that it does not require specialized hardware, making the solution a lot simpler, less expensive and suitable for Linux based "commodity" hardware.


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
Oracle:

+ --------+    +--------+    +--------+   +--------+  
| Node  0  |    | Node  1  |    | Node  2  |   | Node  3  | 
+ ---+----+    +---+----+    +---+----+   +---+----+  
    |             |             |            |
    + -------------+------++-----+------------+ 
     ____________________||__________________
    <________________________________________>
    |                                        |
    |              Shared Storage            |
    |                                        |
    <________________________________________>


DB2:
              High Speed Interconnect

         + -------------+-------------+---------------------+ 
         |             |             |                     |     
    + ----+----+   +----+----+   +----+----+           +----+----+ 
    |Partition|   |Partition|   |Partition|           |Partition|
    |     0     |   |     1     |   |     2     |  .......  |    N    |
    + ----+----+   +----+----+   +----+----+           +----+----+ 
       __|__         __|__         __|__                 __|__   
      <_____>       <_____>       <_____>               <_____>  
      |     |       |     |       |     |               |     |  
      <_____>       <_____>       <_____>               <_____>  


Т.е. чтобы развернуть Оракловский кластер нужно специальное оборудование для реализации Shared Storage. А вроде для IBM кластера нужна куча персоналок + гигабитная связь между ними.


А от о чем говорил г-н Куликов

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
+ --------------------------------------+ 
| + ---------------+  +---------------+ | 
| |+ -----+ +-----+|  |+-----+ +-----+| | 
| || CPU | | CPU ||  || CPU | | CPU || |
| |+ -----+ +-----+|  |+-----+ +-----+| | 
| |+ -------------+|  |+-------------+| | 
| ||   Memory    ||  ||   Memory    || |
| ||             ||  ||             || |
| |+ -------------+|  |+-------------+| | 
| |+ -------------+|  |+-------------+| | 
| || Disks       ||  || Disks       || |
| || ______      ||  || ______      || |
| ||<______>     ||  ||<______>     || |
| ||<______>__   ||  ||<______>__   || |
| ||  <_______>  ||  ||  <_______>  || |
| ||  <_______>  ||  ||  <_______>  || |
| |+ -------------+|  |+-------------+| | 
| |  Partition  0   |  |  Partition  0   | |
| + ---------------+  +---------------+ | 
|              SMP Box  0                |
+ --------------------------------------+ 

Т.е. в SMP машине при большом количестве процессоров производительность
растёт нелинейно. Типа из-за борьбы за разделяемые ресурсы. А в этом случае
каждому разделу базы данных отводятся свои память, диски, процессоры.
Дескать рост производительности должен быть более линейным.
По идее поэкспериментировать с кластером DB2 - подешевле нежели с Ораклом. Все дело упрется в лицензию PDF (Database Partition Feture)
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32640764
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Розетта всё-таки не OLTP система... да и так это было, игрушка, типа "Могём"!
Насколько я понял там взяли действующую системку, часть (очень малую) функционала перелопатили под MS SQL и протестили на розеттовских данных. Поглядели - да, вроде получается. А так, чтобы серъезно... нету там такого... тем более что большая часть запросов там - безиндексные, на полные сканы таблиц...
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32640819
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenman
Т.е. чтобы развернуть Оракловский кластер нужно специальное оборудование для реализации Shared Storage. А вроде для IBM кластера нужна куча персоналок + гигабитная связь между ними.


Да это будет работать только HA в таком случае не очень. Кстати можно в использовать микс ОС. Одна нода на Sun, другая AIX третья HP-UX, четветая linux на pSeries (Linux и Windows/intel не получится так как big endian, small endian). Только опять проблемы с HA.

gardenman
Т.е. в SMP машине при большом количестве процессоров производительность
растёт нелинейно. Типа из-за борьбы за разделяемые ресурсы. А в этом случае
каждому разделу базы данных отводятся свои память, диски, процессоры.
Дескать рост производительности должен быть более линейным.

Не дескать, а на самом деле. Я беседовал с лабораторией они гоняли кучу тестов и 8 узлов в 32 процессорной машине на DWH workload производительнее на 15 и более %.
gardenman
По идее поэкспериментировать с кластером DB2 - подешевле нежели с Ораклом. Все дело упрется в лицензию PDF (Database Partition Feture)

Можно и на VMWARE все это настроить. Ты не говори про лицензию ты попробуй. За 90 дней обыгаться можно до потери сознания и пульса :)
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32640848
Фотография Сергей Тихонов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenmanВот нарыл в документации:
Database Clustering Architectures: There are two primary database clustering architectures: shared-disk and shared-nothing. Shared-disk is used by Oracle RAC. DB2 for Linux employs shared-nothing.

In a shared-disk environment, each database node has its own processors but shares the disks with other nodes. Therefore all the processors can access all the disks in the cluster. This introduces additional overhead for coordinating resources and locks between nodes. For example if Node 1 wants to access data on a certain disk that has been locked for update by another node in the cluster, Node 1 must wait for other nodes to complete their operations. While this works well when there are few nodes in the cluster (e.g. mainframe environments), the overhead for distributed lock management and cache coherency issues can severely limit scalability and introduce performance degradation for 4 or more nodes, making it impractical to exploit economies of large clusters on Linux. Furthermore this approach involves specialized hardware and software for shared disk and cache management, making it a lot more expensive than shared-nothing.
Shared-nothing: As the name implies, partitions (nodes) in a shared-nothing environment do not share processors, memory or disks with partitions on other machines. Each partition acts on its own subset of data. Since each partition has its own private resources, this approach does not involve any resource contention with other servers, lending itself to virtually unlimited scalability. This is one reason DB2 for Linux can support up to 1000 partitions. And since there is no coordination overhead for accessing resources, additional machines can easily be added to the cluster with linearly scalable performance, which implies, if doubling of the data volume is matched by the doubling of the cluster resources, the high performance of the database will be maintained at the same level. If one partition in a cluster fails, its resources can dynamically be transferred to another machine, ensuring high availability. Another benefit of the shared nothing approach used by DB2 for Linux is that it does not require specialized hardware, making the solution a lot simpler, less expensive and suitable for Linux based "commodity" hardware.
По этому поводу есть оччень интересный документ - сравнение архитектур scale up vs. scale out : http://www.unisys.com/eprise/main/admin/corporate/doc/scale_up.pdf
Там, правда, рассматривается MSSQL. Хотелось бы услышать (а лучше прочитать) нечто подобное по поводу СУБД от IBM...
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32640884
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
EugeneS

Nikolay Kulikov
Ну как же офис уже открыли.
А по поводу 32-bit и АWE. Зачем если можно без этого.
Предположим имеем машину 4 процессора 16GB памяти. Запускаем 4 Instance DB2/Informix XPS каждый instance берет свои 4GB и обслуживает свою часть БД. Без всяких AWE.


А что будет, если один и тот же блок понадобиться и в том и в другом инстансе? Как там насчет Interconnect?


Что вы подразумеваете по Interconnect?
Логически транзакции и таблицы у серверов общие.


[/quot]
Informix говорите?
Это уже мертывй продукт. Я даже не считаю нужным его обсуждать.
Если вы так не считаете, то скажите зачем тогда IBM две СУБД?[/quot]

Технологии Informix живут и будут жить в продуктах IBM, как эти
продукты будут называться - вопрос десятый.
От том что сам IBM думает по поводу этих технологий есть любопытный документ:
http://] http://www.snt.com.ru/upload/images/downloads/unallocated/informix_white_paper.pdf

По моим данным выход IDS 9.5 выходит в конце этого года.
Сейчас IBM развивает и поддерживает продукты Informix не хуже, чем это делалось до приобретения.

С уважением onstat-.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641105
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IBM говоря о преимуществах shared nothing правда забыл упомянуть о том, как пользователь может работать с данными, находящимися на разных нодах. Как балансировать нагрузку с ростом данных равномерно по срезу кластеров, учитывая общеизвестный принцип Паретто 20/80. Если данные шарятся между кластерами, то как их синхронизировать.
...
Рейтинг: 0 / 0
25 сообщений из 307, страница 2 из 13
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Проект построения большой БД - давайте пообсуждаем
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]