Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 25 26 27 28 29 30 [31] 32 33 34   вперед  Ctrl
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
ЛП

Так вы возьмите и докажите. Больше месяца уже ждем-ссс.

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

Вы утверждали, что FO на порядки быстрее? Ну тогда вы должны показать время около 18 секунд - на машине, сравнимой с ASCRUS'овской. Или хотя бы порядка 70 секунд - на своей машине.

Или показывайте время, или забудьте про разницу "на порядки" и идите рассказывать сказки - в детский сад.


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

Сразу замечу, я провел дастаточно много тестов меняя самые разнообразные настройки как для FO, так и для Sybase. В целом, кардинального влияния на результаты это не оказывает (если конечно не задаваться целью застопорить систему). Итак, представляю полученные результаты ...
10 июн 05, 16:19    [1614236]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Исходные коды тестового приложения для FastObjects t7 (С++)

... .hcd - файл

//********************************
// MainTable
//********************************

#read <ptstring.hxx>

persistent class MainTable
{
public:
	int		id;
	PtString	name;
};


//********************************
// ChildTable
//********************************


persistent class ChildTable
{
public:
	int 		id;
	PtString 	name;
	ondemand<MainTable>	main_id;
};


typedef lset<ondemand<MainTable>> OnDemandMainTableSet;
typedef ondemand<MainTable> OnDemandMainTable;




... .cpp - файл

#include "stdafx.h"
#include <poet.hxx>
#include "classes.hxx"

#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#include <iostream>
using namespace std;

#define RAND_MAX = 4999999;

void err_msg(char* err_msg, PtBase* pObjBase)
{
	PtBase::POET()->UngetBase(pObjBase);
	DeinitPOET();
	cout << err_msg << endl;
	return;
}

int main(void)
{
	char buffer[10]; 
	int err;

	OnDemandMainTable odpMt;

	//Инициализация
	InitPOET( PtTransactionByBase, "TestClient");
	PtBase* pObjBase;
	err = PtBase::POET()->GetBase("LOCAL", "Test1", pObjBase);
	if (err < 0) {err_msg("Could not open database", pObjBase); return(0);}
	srand( (unsigned)time( NULL ) );

	//  Начинаем ввод данных
	int st = (int)time( NULL );
	_strtime(buffer);
	cout << "Start: " << buffer << endl;

	PtTransaction * pTrans1 = new PtTransaction;
	PtBase::POET()->SetCurrentTransaction( pTrans1 );
	pTrans1->SetUseShadowIndexes( PtFALSE );
             pTrans1->SetRefreshOnAbort( PtFALSE );
             pTrans1->SetCheckPoint( 100000 );
	pTrans1->RegisterResource( pObjBase );
	pTrans1->Begin();

	int i = 1;
	do 
	{
        MainTable * pMt = new MainTable();
        pMt->id = i;
		_itoa(i, buffer, 10);
        pMt->name = (PtString)"Rec: " + (PtString)buffer;
		pMt->Assign(pObjBase);
		err = pMt->Store(PtFLAT);
		if (err < 0) {err_msg("Could not store object", pObjBase); return(0);}
        if (i % 100000 == 0) 
		{
			cout << "Primary " << buffer << " rows complete: ";
			_strtime(buffer);
			cout << buffer << endl;
		}
		delete pMt;
    }  while (++i <= 5000000 );
	pTrans1->Commit();

	_strtime(buffer);
	cout << "Generate main complete: " << buffer << endl;
	
	MainTableAllSet allMts(pObjBase);
	err = allMts.SortByIndex("idIX");
	if (err < 0) {err_msg("Could not initialise set", pObjBase); return(0);} 

	PtLockSpec * PtL = new PtLockSpec(PtLK_NONE, PtFLAT);
	int j = 1;
	do
	{
		ChildTable * pCt = new ChildTable();
        pCt->id = j;
		_itoa(j, buffer, 10);
        pCt->name = (PtString)"Rec: " + (PtString)buffer;
		int searchKey = rand()+1;
		err = allMts.FindKey(PtINT_T, &searchKey, 1);
		if (err < 0) {err_msg("Could not find object by key", pObjBase); return(0);} 
		err = allMts.Get(odpMt, 0, PtCURRENT, PtL); 
		pCt->main_id = odpMt;
		if (err < 0) {err_msg("Could not get object from DB", pObjBase); return(0);}
		pCt->Assign(pObjBase); // Methods inherited from PtObject
		err = pCt->Store(PtFLAT);
		if (err < 0) {err_msg("Could not store object", pObjBase); return(0);}
        if (j % 100000 == 0) 
		{
			cout << "Child " << buffer << " rows complete: ";
			_strtime(buffer);
			cout << buffer << endl;
		}
		delete pCt;
    } while (++j <= 5000000 ) ;

	_strtime(buffer);
	cout << "Finish: " << buffer << endl;
	_itoa((int)time(NULL) - st, buffer, 10);
    cout << "Execution time: " << buffer << " seconds" << endl;

	// now we have an open PtBase...let’s close it
	PtBase::POET()->UngetBase(pObjBase);
	DeinitPOET();
	return 0;
}
10 июн 05, 16:28    [1614264]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Итак, тестирование FastObjects осуществлялось с помощью приложения, представленного выше, а Sybase тестировался по SQL-коду, который ASCRUS привел ранее.

Выше я уже приводил свой результат для Sybase при следующих тестовых данных: 5000000 - MainTable, 5000000 - Child Table. Напомню итог: 7300 секунд.

Теперь смотрим трейс для FastObjects:

Start: 12:13:38
Primary 100000 rows complete: 12:13:55
Primary 200000 rows complete: 12:14:14
Primary 300000 rows complete: 12:14:31
Primary 400000 rows complete: 12:14:48
Primary 500000 rows complete: 12:15:05
Primary 600000 rows complete: 12:15:22
Primary 700000 rows complete: 12:15:39
Primary 800000 rows complete: 12:15:56
Primary 900000 rows complete: 12:16:13
Primary 1000000 rows complete: 12:16:30
Primary 1100000 rows complete: 12:16:47
Primary 1200000 rows complete: 12:17:04
Primary 1300000 rows complete: 12:17:21
Primary 1400000 rows complete: 12:17:38
Primary 1500000 rows complete: 12:17:54
Primary 1600000 rows complete: 12:18:13
Primary 1700000 rows complete: 12:18:29
Primary 1800000 rows complete: 12:18:46
Primary 1900000 rows complete: 12:19:03
Primary 2000000 rows complete: 12:19:20
Primary 2100000 rows complete: 12:19:38
Primary 2200000 rows complete: 12:19:55
Primary 2300000 rows complete: 12:20:12
Primary 2400000 rows complete: 12:20:29
Primary 2500000 rows complete: 12:20:46
Primary 2600000 rows complete: 12:21:03
Primary 2700000 rows complete: 12:21:20
Primary 2800000 rows complete: 12:21:37
Primary 2900000 rows complete: 12:21:55
Primary 3000000 rows complete: 12:22:12
Primary 3100000 rows complete: 12:22:29
Primary 3200000 rows complete: 12:22:46
Primary 3300000 rows complete: 12:23:03
Primary 3400000 rows complete: 12:23:20
Primary 3500000 rows complete: 12:23:37
Primary 3600000 rows complete: 12:23:54
Primary 3700000 rows complete: 12:24:10
Primary 3800000 rows complete: 12:24:27
Primary 3900000 rows complete: 12:24:44
Primary 4000000 rows complete: 12:25:01
Primary 4100000 rows complete: 12:25:18
Primary 4200000 rows complete: 12:25:35
Primary 4300000 rows complete: 12:25:52
Primary 4400000 rows complete: 12:26:09
Primary 4500000 rows complete: 12:26:26
Primary 4600000 rows complete: 12:26:42
Primary 4700000 rows complete: 12:27:00
Primary 4800000 rows complete: 12:27:17
Primary 4900000 rows complete: 12:27:34
Primary 5000000 rows complete: 12:27:51
Generate main complete: 12:27:51
Child 100000 rows complete: 12:28:57
Child 200000 rows complete: 12:29:32
Child 300000 rows complete: 12:30:08
Child 400000 rows complete: 12:30:43
Child 500000 rows complete: 12:31:18
Child 600000 rows complete: 12:31:54
Child 700000 rows complete: 12:32:29
Child 800000 rows complete: 12:33:04
Child 900000 rows complete: 12:33:40
Child 1000000 rows complete: 12:34:15
Child 1100000 rows complete: 12:34:51
Child 1200000 rows complete: 12:35:26
Child 1300000 rows complete: 12:36:02
Child 1400000 rows complete: 12:36:37
Child 1500000 rows complete: 12:37:13
Child 1600000 rows complete: 12:37:48
Child 1700000 rows complete: 12:38:24
Child 1800000 rows complete: 12:38:59
Child 1900000 rows complete: 12:39:37
Child 2000000 rows complete: 12:40:13
Child 2100000 rows complete: 12:40:49
Child 2200000 rows complete: 12:41:24
Child 2300000 rows complete: 12:42:00
Child 2400000 rows complete: 12:42:35
Child 2500000 rows complete: 12:43:11
Child 2600000 rows complete: 12:43:46
Child 2700000 rows complete: 12:44:21
Child 2800000 rows complete: 12:44:57
Child 2900000 rows complete: 12:45:32
Child 3000000 rows complete: 12:46:07
Child 3100000 rows complete: 12:46:43
Child 3200000 rows complete: 12:47:18
Child 3300000 rows complete: 12:47:53
Child 3400000 rows complete: 12:48:28
Child 3500000 rows complete: 12:49:04
Child 3600000 rows complete: 12:49:39
Child 3700000 rows complete: 12:50:14
Child 3800000 rows complete: 12:50:50
Child 3900000 rows complete: 12:51:26
Child 4000000 rows complete: 12:52:01
Child 4100000 rows complete: 12:52:38
Child 4200000 rows complete: 12:53:14
Child 4300000 rows complete: 12:53:49
Child 4400000 rows complete: 12:54:25
Child 4500000 rows complete: 12:55:02
Child 4600000 rows complete: 12:55:38
Child 4700000 rows complete: 12:56:13
Child 4800000 rows complete: 12:56:49
Child 4900000 rows complete: 12:57:24
Child 5000000 rows complete: 12:57:59
Finish: 12:57:59
Execution time: 2661 seconds

Быстрее почти в три раза.
Но, это конечно не два порядка. Скажете, что разговоры о порядках - туфта?
Только сначала давайте увеличим объемы тестовых данным и посмотрим, что получится ...
10 июн 05, 16:37    [1614309]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
MainTable, ChildTable - 10млн.

Sybase ASA

Start: 2005-06-03 12:46:45.955
Primary 100000 rows complete: 2005-06-03 12:46:51.939
Primary 200000 rows complete: 2005-06-03 12:46:59.377
Primary 300000 rows complete: 2005-06-03 12:47:05.252
Primary 400000 rows complete: 2005-06-03 12:47:11.252
Primary 500000 rows complete: 2005-06-03 12:47:17.205
...
Primary 8800000 rows complete: 2005-06-03 12:57:00.158
Primary 8900000 rows complete: 2005-06-03 12:57:07.002
Primary 9000000 rows complete: 2005-06-03 12:57:13.408
Primary 9100000 rows complete: 2005-06-03 12:57:19.799
Primary 9200000 rows complete: 2005-06-03 12:57:26.189
Primary 9300000 rows complete: 2005-06-03 12:57:32.674
Primary 9400000 rows complete: 2005-06-03 12:57:39.283
Primary 9500000 rows complete: 2005-06-03 12:57:45.580
Primary 9600000 rows complete: 2005-06-03 12:57:51.924
Primary 9700000 rows complete: 2005-06-03 12:57:58.252
Primary 9800000 rows complete: 2005-06-03 12:58:04.502
Primary 9900000 rows complete: 2005-06-03 12:58:11.299
Primary 10000000 rows complete: 2005-06-03 12:58:18.486
Generate main complete: 2005-06-03 12:58:18.627
Child 100000 rows complete: 2005-06-03 13:00:23.705
Child 200000 rows complete: 2005-06-03 13:01:02.502
Child 300000 rows complete: 2005-06-03 13:02:38.486
Child 400000 rows complete: 2005-06-03 13:02:49.955
Child 500000 rows complete: 2005-06-03 13:04:38.017
Child 600000 rows complete: 2005-06-03 13:04:49.939
Child 700000 rows complete: 2005-06-03 13:05:02.283
Child 800000 rows complete: 2005-06-03 13:06:42.252
Child 900000 rows complete: 2005-06-03 13:08:40.877
Child 1000000 rows complete: 2005-06-03 13:08:54.095
Child 1100000 rows complete: 2005-06-03 13:09:06.095
Child 1200000 rows complete: 2005-06-03 13:09:17.892
Child 1300000 rows complete: 2005-06-03 13:09:29.580
...
Child 9100000 rows complete: 2005-06-04 04:10:59.599
Child 9200000 rows complete: 2005-06-04 04:29:56.719
Child 9300000 rows complete: 2005-06-04 04:49:10.432
Child 9400000 rows complete: 2005-06-04 05:08:43.386
Child 9500000 rows complete: 2005-06-04 05:28:26.141
Child 9600000 rows complete: 2005-06-04 05:48:51.733
Child 9700000 rows complete: 2005-06-04 06:08:59.983
Child 9800000 rows complete: 2005-06-04 06:29:33.045
Child 9900000 rows complete: 2005-06-04 06:50:07.295
Child 10000000 rows complete: 2005-06-04 07:11:12.186
Finish: 2005-06-04 07:11:12.436
Execution time: 66267.372 seconds

Размер файла БД: 1153976 кБ



FastObjects t7

Start: 13:06:16
Primary 100000 rows complete: 13:06:33
Primary 200000 rows complete: 13:06:50
Primary 300000 rows complete: 13:07:07
Primary 400000 rows complete: 13:07:24
Primary 500000 rows complete: 13:07:41
Primary 600000 rows complete: 13:07:57
Primary 700000 rows complete: 13:08:14
Primary 800000 rows complete: 13:08:31
Primary 900000 rows complete: 13:08:48
Primary 1000000 rows complete: 13:09:04
Primary 1100000 rows complete: 13:09:21
...
Primary 9500000 rows complete: 13:32:54
Primary 9600000 rows complete: 13:33:11
Primary 9700000 rows complete: 13:33:28
Primary 9800000 rows complete: 13:33:44
Primary 9900000 rows complete: 13:34:01
Primary 10000000 rows complete: 13:34:18
Generate main complete: 13:34:18
Child 100000 rows complete: 13:35:21
Child 200000 rows complete: 13:35:57
Child 300000 rows complete: 13:36:32
Child 400000 rows complete: 13:37:08
Child 500000 rows complete: 13:37:44
Child 600000 rows complete: 13:38:19
Child 700000 rows complete: 13:38:55
Child 800000 rows complete: 13:39:31
...
Child 9100000 rows complete: 14:29:08
Child 9200000 rows complete: 14:29:44
Child 9300000 rows complete: 14:30:19
Child 9400000 rows complete: 14:30:55
Child 9500000 rows complete: 14:31:31
Child 9600000 rows complete: 14:32:07
Child 9700000 rows complete: 14:32:42
Child 9800000 rows complete: 14:33:18
Child 9900000 rows complete: 14:33:54
Child 10000000 rows complete: 14:34:30
Finish: 14:34:30
Execution time: 5294 seconds

Размер файла БД: 2676000 кБ


Итак, порядки при сравнении производительности с ростом объема тестовых данных похоже начинают просматриваться? Увелечим объем данных ...
10 июн 05, 16:44    [1614353]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
MainTable, ChildTable - 40млн.

Sybase ASA

Start: 2005-06-06 19:04:16.513
Primary 100000 rows complete: 2005-06-06 19:04:21.763
Primary 200000 rows complete: 2005-06-06 19:04:27.389
Primary 300000 rows complete: 2005-06-06 19:04:33.327
Primary 400000 rows complete: 2005-06-06 19:04:38.577
Primary 500000 rows complete: 2005-06-06 19:04:43.765
Primary 600000 rows complete: 2005-06-06 19:04:49.187
...
Primary 39300000 rows complete: 2005-06-06 19:44:09.978
Primary 39400000 rows complete: 2005-06-06 19:44:15.916
Primary 39500000 rows complete: 2005-06-06 19:44:23.979
Primary 39600000 rows complete: 2005-06-06 19:44:30.651
Primary 39700000 rows complete: 2005-06-06 19:44:36.464
Primary 39800000 rows complete: 2005-06-06 19:44:42.387
Primary 39900000 rows complete: 2005-06-06 19:44:48.403
Primary 40000000 rows complete: 2005-06-06 19:44:54.513
Generate main complete: 2005-06-06 19:44:54.700
Child 100000 rows complete: 2005-06-06 19:59:10.547
Child 200000 rows complete: 2005-06-06 20:14:14.304
Child 300000 rows complete: 2005-06-06 20:32:02.745
Child 400000 rows complete: 2005-06-06 20:51:42.337
Child 500000 rows complete: 2005-06-06 21:12:37.978
...
Child 11400000 rows complete: 2005-06-10 01:09:42.941
Child 11500000 rows complete: 2005-06-10 01:56:49.313
Child 11600000 rows complete: 2005-06-10 02:44:05.226
Child 11700000 rows complete: 2005-06-10 03:31:28.760
Child 11800000 rows complete: 2005-06-10 04:19:06.843
Child 11900000 rows complete: 2005-06-10 05:07:14.410
Child 12000000 rows complete: 2005-06-10 05:55:17.687
Child 12100000 rows complete: 2005-06-10 06:43:15.601
Child 12200000 rows complete: 2005-06-10 07:31:09.859
Child 12300000 rows complete: 2005-06-10 08:18:55.125
Child 12400000 rows complete: 2005-06-10 09:06:35.536
Child 12500000 rows complete: 2005-06-10 09:55:18.118
...
Execution time: ~1200000 seconds


FastObjects t7

Start: ~11:00
....
Child 3500000 rows complete: 13:19:43
Child 3600000 rows complete: 13:20:23
Child 3700000 rows complete: 13:21:04
Child 3800000 rows complete: 13:21:44
Child 3900000 rows complete: 13:22:24
Child 4000000 rows complete: 13:23:04
Child 4100000 rows complete: 13:23:45
...
Child 6200000 rows complete: 13:39:24
Child 6300000 rows complete: 13:40:09
Child 6400000 rows complete: 13:40:56
Child 6500000 rows complete: 13:41:42
Child 6600000 rows complete: 13:42:24
Child 6700000 rows complete: 13:43:07
Child 6800000 rows complete: 13:43:51
Child 6900000 rows complete: 13:44:35
Child 7000000 rows complete: 13:45:19
...
Child 32800000 rows complete: 16:45:40
Child 32900000 rows complete: 16:46:21
Child 33000000 rows complete: 16:47:02
Child 33100000 rows complete: 16:47:41
Child 33200000 rows complete: 16:48:24
...
Finish: ~17:30
Execution time: ~23400 seconds

Посмотрим на эти трейсы. Что мы видим? FastObjects для записи 100тыс. Child-элементов тратит ~40сек, а Sybase - 50мин., что в 75 раз медленнее.

Желающие могут сами провести эксперименты с большими объемами данных и получить еще большую разницу ...
10 июн 05, 16:56    [1614409]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Какие выводы из всего этого?

Еще раз повторю:

Sybase проиграет FO на задаче массированного ввода структурированных данных с проверкой констрейнтов и формированием индексов.

РСУБД проиграют ООСУБД на задаче массированного ввода структурированных данных с проверкой констрейнтов и формированием индексов.


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

Реабилитируя РСУБД, скажу, что все-таки запись больших объемов сложноструктурированных данных с проверкой констрейнтов и формированием индексов - случай достаточно специфический. Он востребован обычно в разнообразном оборудовании и системах контроля и сбора информации с датчиков. В других ситуациях, таких, например, как предложенный ASCRUS более простой тест Sybase и FO показывают приблизительно равные результаты.

И в заключение отмечу еще один аспект, касающийся именно FastObjects. Эта ООСУБД написана в первую очередь для встраиваемого применения. Во время выполнения всех тестовых заданий объем оперативной памяти, занимаемой тестовым приложением (со встроенной СУБД) не превышал 1,5-4,5 Мб, в то время как Sybase "получал" не менее 260 Мб.
10 июн 05, 17:10    [1614470]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Бедная ASA - интересно, насколько же лог-файл вырос :) С выводами согласен - не созданы РСУБД, чтобы со счетчиков писать непрерывно. Например, сейчас у нас на форуме Sybase примерно такая же тема муссируется по СУБД для ОС реального времени, Линтеровцы очень благодарят Sybase, что в свое время они увели с QNX ASA (5-ая версия поддерживала эту ОС), освободив место под солнцем Линтеру.

Хотя даже для счетчиков все зависит еще и от порядка получения показаний с них - например, многие пишут их в CSV файлы и потом порциями грузят их в ASA, т.е. не через INSERT, а LOAD TABLE FROM - здесь работают механизмы оптимизированные на загрузку данных большого обьема и скорости загрузки данных уже будут отличаться в порядки. В принципе это применительно к любой порядочной РСУБД, которая обязана иметь механизм загрузки данных большого обьема как раз для таких случаев (например в ASA специально для таких вещей даже сделана поддержка фиксирования имен подгружаемых файлов в лог-файле, что позволяет ей в случае остановки сервера во время подгрузки файла, после рестарта при нахождении файла автоматически повторить операцию подгрузки или же отказаться в зависимости от опций). Но чтобы протестировать эти механизмы, необходимо написать на тех же Java/C программу, которая генерит куски-файлы CSV, эмулируя работу считывания показаний с датчиков и организовать событие в ASA на подгрузку файлов через установленное время.
10 июн 05, 17:41    [1614618]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
XM
Member

Откуда: ненадолго из запоя
Сообщений: 1264
По результатам тестов в худшем случае Sybase ASA тратит 30ms на добавление одной записи, FastObjects - 0.5ms.
Мне вот что интересно - пример реальной задачи, где понадобилось бы вносить запись в базу каждые 0.5ms и хранить 40млн. таких записей?
10 июн 05, 18:13    [1614773]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Alexey Rovdo

>Надеюсь, что некоторые все-таки признают очевидное и мы сможем двинуться дальше.

Многие очевидные вещи при более внимательном рассмотрении оказывались туфтой.

>Итак, порядки при сравнении производительности с ростом объема тестовых данных похоже начинают просматриваться? Увелечим объем данных ...

Т.е. отсюда следует что с увеличением количества записей процесс добавления заметно (на порядки) замедляется. Это неверно. Мы неоднократно проводили эксперименты, в том числе мастер-детайл, до 6 млн записей вообще никакого замедления не наблюдается. Врядли дополнительные 4 млн существенно изменят картину.

Ищите ошибку.
11 июн 05, 03:19    [1615335]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
BaZa
Guest
Алексей, примите поздравления!
11 июн 05, 15:15    [1615622]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Мимо пробегал....
Guest
Ув. Алексей.

Не могли бы Вы для людей, незнакомых с системой постоянного хранения программных объектов FO, дать текст вашего теста с комментариями. А то всякие
автор
...
err = allMts.SortByIndex("idIX");
...

попросту непонятны. Думаю, что синтаксис С++ объяснять не надо, но смысл употребляемых Вами вызовов и переменных стоит расшифровать.
11 июн 05, 17:01    [1615702]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
BaZa
Алексей, примите поздравления!


В очередной раз. :)

С очередной окончательной победой, так сказать.
12 июн 05, 02:38    [1616004]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
ASCRUS
Бедная ASA - интересно, насколько же лог-файл вырос :) С выводами согласен - не созданы РСУБД, чтобы со счетчиков писать непрерывно. Например, сейчас у нас на форуме Sybase примерно такая же тема муссируется по СУБД для ОС реального времени, Линтеровцы очень благодарят Sybase, что в свое время они увели с QNX ASA (5-ая версия поддерживала эту ОС), освободив место под солнцем Линтеру.


Вероятно Линтеровцы могут быть благодарны и Poet (теперь и Versant), которая в свое время не стала портировать FastObjects на платформу QNX. Из ОС РВ FastObjects поддерживает VxWorks.

ASCRUS

Хотя даже для счетчиков все зависит еще и от порядка получения показаний с них - например, многие пишут их в CSV файлы и потом порциями грузят их в ASA, т.е. не через INSERT, а LOAD TABLE FROM - здесь работают механизмы оптимизированные на загрузку данных большого обьема и скорости загрузки данных уже будут отличаться в порядки. В принципе это применительно к любой порядочной РСУБД, которая обязана иметь механизм загрузки данных большого обьема как раз для таких случаев (например в ASA специально для таких вещей даже сделана поддержка фиксирования имен подгружаемых файлов в лог-файле, что позволяет ей в случае остановки сервера во время подгрузки файла, после рестарта при нахождении файла автоматически повторить операцию подгрузки или же отказаться в зависимости от опций). Но чтобы протестировать эти механизмы, необходимо написать на тех же Java/C программу, которая генерит куски-файлы CSV, эмулируя работу считывания показаний с датчиков и организовать событие в ASA на подгрузку файлов через установленное время.


Думаю, что мы оба вполне адекватно оцениваем ограниченность той модели, которая была использована в наших тестах. Но тут есть один скорее теоретический аспект, который я бы хотел особенно отметить. Ведь многие мои оппоненты в разных ветках этого форума неоднократно ссылались на преимущества РСУБД в контексте более полной поддержки в них ОЦ. Но ускорение решения рассмотренной нами задачи на РСУБД безусловно возможно (в т.ч. и на порядки), но только ценой отказа от ОЦ внутри СУБД.

Тут будет также вполне уместно ответить и на вопрос XM.

XM
По результатам тестов в худшем случае Sybase ASA тратит 30ms на добавление одной записи, FastObjects - 0.5ms.
Мне вот что интересно - пример реальной задачи, где понадобилось бы вносить запись в базу каждые 0.5ms и хранить 40млн. таких записей?


Разумеется таких задач не очень много, но они существуют. И за примерами достаточно обратиться к сферам использования FO. А это - телекоммуникационное оборудование, системы принятия решений реального времени, военные симуляторы и системы управления (управление радаром наведения и т.п.). К тому же я еще раз подчеркну, что наш пример потребовал столь большого количества тестовых данных из-за примитивности структуры данных (две связанных одним отношением таблицы). Но чем сложнее будут эти структуры, тем скорее и явственнее в подобных задачах будут проявляться преимущества ООСУБД.
14 июн 05, 11:59    [1618541]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
c127

Многие очевидные вещи при более внимательном рассмотрении оказывались туфтой.


Т.е. не может быть и все тут?

c127

Т.е. отсюда следует что с увеличением количества записей процесс добавления заметно (на порядки) замедляется. Это неверно. Мы неоднократно проводили эксперименты, в том числе мастер-детайл, до 6 млн записей вообще никакого замедления не наблюдается.


Выложите исходники ваших экспериментов. Исходники ASCRUS и мои перед вами. Все эксперименты я проводил именно с ними.

По делу же могу заметить, что замедления почти не наблюдается только до тех пор, пока хватает кэша (это вполне просматривается в приведенных трейсах). Если же у вас достаточно мощный сервак с большой памятью, то на двух таблицах с примитивными данными кэш забъется очень и очень не скоро. Возможно надо экспериментировать с десятками и даже сотнями миллионов записей или ограничивать размер кэша.
14 июн 05, 12:09    [1618579]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Foxi - Voxi
Guest
2 Alexey Rovdo

Да, развели Вас. Спор о преимуществах/недостатках свалился на сравнение скорости записи/чтения данных.

Вы серьезно думаете, что люди, которые рассматривают ООСУБД с т.зр. именно быстродействия, будут их использовать? В лучшем случае они согласятся с Вами: "да, есть какие-то объектные СУБД, дико шустрые. Только вот нафиг они нужны - непонятно". А если не убедите, что они шустрые, то будут говорить: "есть какие-то нафиг не нужные ОО СУБД, медленные - обалдеть. Фигня полная. И непонятно, к тому же, для чего нужные".

А о преимуществах использования ОО подхода им ПОФИГ. Они не понимают его. Так что, по-моему, зря Вы тут столько времени гробите. Этот форум - SQL. Для нормальных людей.

Если бы Ваша СУБД Fast Objects была в несколько раз медленнее, чем Sybase - я бы все равно ее использовал только из-за того, то она ОО. Пусть даже в ней нет реализации методов объектов констреинтов на серверной стороне.

Главное - надежность и скорость при проектировании СЛОЖНЫХ систем. Вот для чего нужны ООСУБД. Люди должны думать о предметной области, а не о том, как данные по табличкам размазывать. Вот что нужно объяснять. Только это нужно не нам,старперам, а студентам впаривать, у кого мозги пока не 2d - реляционные.
Правда, это на объемах продаж продуктов от Versant скажется не сегодня, и даже не завтра.

Люди ради ОО - методов проектирования даже O/R маппинг используют, а все потому, что нет доступных ОСУБД.

Все убивает стоимость лицензии...
14 июн 05, 12:53    [1618822]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
XM
Member

Откуда: ненадолго из запоя
Сообщений: 1264

Foxi - Voxi wrote:
> Главное - надежность и скорость при проектировании СЛОЖНЫХ систем. Вот
> для чего нужны ООСУБД.
А это реально - быстро спроектированная надежная сложная система???

> Только это нужно не нам,старперам, а студентам впаривать, у кого мозги
> пока не 2d - реляционные.
2d-реляционные? сильно

Posted via ActualForum NNTP Server 1.2

14 июн 05, 13:01    [1618861]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Foxi - Voxi
А о преимуществах использования ОО подхода им ПОФИГ. Они не понимают его. Так что, по-моему, зря Вы тут столько времени гробите. Этот форум - SQL. Для нормальных людей.

Как раз наоборот - понимаем, что на ОО нельзя полноценно описать предметную область, недорос еще. Поэтому и приходится данные "размазывать" вместо того, чтобы предметную область описывать. Или Вы серьезно думаете, что мир можно уложить в ОО-модель и ее принципов хватит на все, про все и что если бы это поняли все, то настало светлое радостное будующее ?

P.S. Как то странно, что многие ОО-приверженцы думают, что те, кто проектирует БД на РСУБД делают это исключительно потому, что стары и ничего не понимают в ООП. Очень большое заблуждение, многие именно на нем и начинали с конца 80-х и начала 90-х, когда еще не было не то, что мышерисовалок формочек, но и самих мышек и все писалось ручками с кучей ограничений. Если посмотреть, то основная масса этих специалистов как раз сейчас на РСУБД и сидит. Может быть это как раз из за того, что они наоборот - слишком хорошо знают ООП и то, что на нем можно действительно хорошо реализовывать на текущий момент его развития, а с чем не стоит связываться ?
14 июн 05, 14:12    [1619116]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Мимо пробегал...
Guest
Я так и не дождался расшифрованного листинга. Но тем не менее, попытаюсь высказать свою точку зрения.

ИМХО это все же некоррктное сравнение. Поясню. В тесте ASCRUS'а в обеих таблицах существует условие PRIMARY KEY, что гарантирует, что добавляемые значения будут уникальными. Ес-но система тратит время на проверку этого условия.

Я не нашел подобного условия в программе FO. Мне конечно скажут "объекты то в ФО все рано уникальны". Но ИМХО как раз в данном случае это не играет роли. В SQL системах запросто могут существовать таблица, в которых отсутсвует ключ - в этих таблицах разные строки могут содержать одинаковое значение(АХТУНГ! -я здесь говорю про SQL, а не про реляционную модель, где эта ситуация не возможна).

Возвращаясь к нашим 5000000 объектам. Насколько я понял из листинга, проверка на уникальнсть атрибута объекта отсутсвует. Соответсвенно можно сделать множество объектов с абсолютно одинаковым состоянием. Псокольку ссылки на эти объекты отсуствуют, то ИМХО эти объекты бесполезны.

У ASCRUS'а система контролирует, что строки различимы по значениям - пользователь зная это значение (а пользователь знает это значение, поскольку именно пользователь его определяет) может обратиться к каждой конретной строке. В тесте Алексея создаются вроде бы различные объекты - но, посколько, они различнаются своим OID, который
1) генерится системой
2) не сохраняется в какой-либо ссылочной переменной,
то, сохранив предложенным Алексеем способом такие объекты, мы не сможем ими дальше пользоваться.

Поясню это так. Есть цикл на добавляющий записи (создающий и сохраняющий объекта). Если в тесте ASCRUS'а, после этого цикла мы попытаемся добавить запись у которой ID = 1, система не допустит выполнение этого действия.

Но я не смог найти подобнорго ограничения в тесте Алексея. Да , в цикле, где значение атрибута ID инициируется значением счетчика, созданные объекты будут уникальны по этому атрибуту. Но это только в данном конкретном случае. А если предположить, что значение ID вводятся от руки? Что, можно создать и сохранить объект, у которого атрибут ID будет совпадать с аналогичным атрибутом уже существующего объекта? (Насколько я понимаю, мы можем создать 5000000 объектов с одинаковым значением этого атрибута.) Если это так, то тест ИМХО некорректен, посколько пример ASCRUS'а функционально мощнее, чем пример Алексея (а за мощность приходится расплачиваться).

PRIMARY KEY - он не только для того, что бы делать FOREIGN KEY, но так же и для того, что бы пользователь мог различить объекты по ЯВНО ЗАДАВАЕМЫМ ДАННЫМ (задаваемым самим пользователем). В тесте Алексея это условие не выполнено.
14 июн 05, 14:34    [1619209]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Мимо пробегал....
Ув. Алексей.

Не могли бы Вы для людей, незнакомых с системой постоянного хранения программных объектов FO, дать текст вашего теста с комментариями.


#include "stdafx.h"
#include <poet.hxx>  // включаем заголовочные файлы из дистрибутива FO
#include "classes.hxx" // включаем заголовочные файлы 
 // автоматически сгенерированные из .hcd - файла

#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#include <iostream>
using namespace std;

#define RAND_MAX = 4999999;

// Ф-я вывода сообщения об ошибке доступа к базе или данным
void err_msg(char* err_msg, PtBase* pObjBase)
{
	PtBase::POET()->UngetBase(pObjBase);
	DeinitPOET();
	cout << err_msg << endl;
	return;
}

int main(void)
{
	char buffer[10]; 
	int err;

	OnDemandMainTable odpMt; // переменная данного типа содержит 
               // только OID объекта класса MainTable, но не его данные

	// Инициализация соединения с БД
            // Некоторые параметры этого соединения 
            // описываются также в ф-ле poet.cfg (здесь не приведен)
	InitPOET( PtTransactionByBase, "TestClient");
	PtBase* pObjBase; // указатель на объект "База данных"
	err = PtBase::POET()->GetBase("LOCAL", "Test1", pObjBase);
	if (err < 0) {err_msg("Could not open database", pObjBase); return(0);}
	srand( (unsigned)time( NULL ) ); // инициализаци ГСЧ

	//  Начинаем ввод данных
	int st = (int)time( NULL );
	_strtime(buffer);
	cout << "Start: " << buffer << endl;

	PtTransaction * pTrans1 = new PtTransaction; // создаем объект "Транзакция"
             // связываем объект "Транзакция" с открытым соединением с БД
	PtBase::POET()->SetCurrentTransaction( pTrans1 );
             // определяем режим обновления индексов при записи внутри транзакции,
             // используем более быстрый режим без теневого обновления индексов (индексы обновляются в конце транзакции)
	pTrans1->SetUseShadowIndexes( PtFALSE );
             // восстанавливать исходное состояние кэша в случае 
             // сброса транзакции не нужно
             pTrans1->SetRefreshOnAbort( PtFALSE );
            // устанавливаем авто-чекпоинт транзакции при накоплении в кэше
            // ста тысяч измененных (новых) объектов
             pTrans1->SetCheckPoint( 100000 );
            // регистрируем ресурс (необходимо обязательно для работы транзакции)
	pTrans1->RegisterResource( pObjBase );
            // начинаем транзакцию
	pTrans1->Begin();

	int i = 1;
	do 
	{
        MainTable * pMt = new MainTable();
        pMt->id = i;
		_itoa(i, buffer, 10);
        pMt->name = (PtString)"Rec: " + (PtString)buffer;
                         // делаем объект, указываемый pMt, сохраняемым (сохраняем в БД)
		pMt->Assign(pObjBase); 
		err = pMt->Store(PtFLAT);
 		if (err < 0) {err_msg("Could not store object", pObjBase); return(0);}
        if (i % 100000 == 0) 
		{
			cout << "Primary " << buffer << " rows complete: ";
			_strtime(buffer);
			cout << buffer << endl;
		}
		delete pMt;
    }  while (++i <= 5000000 );
	pTrans1->Commit();

	_strtime(buffer);
	cout << "Generate main complete: " << buffer << endl;
	
	MainTableAllSet allMts(pObjBase); // Множество всех объектов класса MainTable
            // Определяем порядок доступа к элементам множества allMts 
            // в соотвествии с предопределенным индексом idIX 
            // (уникальный индекс по атрибуту id, определяется в файле poet.cfg) 
	err = allMts.SortByIndex("idIX"); 
	if (err < 0) {err_msg("Could not initialise set", pObjBase); return(0);} 

	PtLockSpec * PtL = new PtLockSpec(PtLK_NONE, PtFLAT); // параметр режима блокировок
	int j = 1;
	do
	{
		ChildTable * pCt = new ChildTable();
        pCt->id = j;
		_itoa(j, buffer, 10);
        pCt->name = (PtString)"Rec: " + (PtString)buffer;
		int searchKey = rand()+1; // генерируем случайный ключ в заданном диапазоне
                         // ищем объект класса MainTable по ключу
		err = allMts.FindKey(PtINT_T, &searchKey, 1);
		if (err < 0) {err_msg("Could not find object by key", pObjBase); return(0);} 
		err = allMts.Get(odpMt, 0, PtCURRENT, PtL); // получаем OID найденного объекта
		pCt->main_id = odpMt; // присваеваем атрибуту-указателю значение выбранного OID
		if (err < 0) {err_msg("Could not get object from DB", pObjBase); return(0);}
		pCt->Assign(pObjBase); // Methods inherited from PtObject
		err = pCt->Store(PtFLAT);
		if (err < 0) {err_msg("Could not store object", pObjBase); return(0);}
        if (j % 100000 == 0) 
		{
			cout << "Child " << buffer << " rows complete: ";
			_strtime(buffer);
			cout << buffer << endl;
		}
		delete pCt;
    } while (++j <= 5000000 ) ;

	_strtime(buffer);
	cout << "Finish: " << buffer << endl;
	_itoa((int)time(NULL) - st, buffer, 10);
    cout << "Execution time: " << buffer << " seconds" << endl;

	// now we have an open PtBase...let’s close it
	PtBase::POET()->UngetBase(pObjBase);
	DeinitPOET();
	return 0;
}


Надеюсь это прояснит некоторые моменты. Если есть вопросы, задавайте ...
14 июн 05, 14:43    [1619245]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Мимо пробегал...

ИМХО это все же некоррктное сравнение. Поясню. В тесте ASCRUS'а в обеих таблицах существует условие PRIMARY KEY, что гарантирует, что добавляемые значения будут уникальными. ...


Уникальность гарантируется введением уникальных индексов. В моем примере был определен уникальный индекс idIX по атрибуту id класса MainTable.
Уникального индекса по классу ChildTable я не вводил.

Возможно тут и есть какие-то аспекты, которые могут несколько сузить применимость рассмотренного примера. Однако они не могут отменить полученных результатов в принципе (зависимость же производительности от активации разных средств контроля целостности я уже подчеркивал). Я попробую доопределить еще один индекс и посмотрю как это скажется на производительности.

Что же касается замечания о том, что OID приходится не конструировать, а выбирать из БД, то с ним согласен. За этим действительно кроется некая специфика именно ООСУБД. Мы не можем сконструировать OID полностью поскольку он содержит физический адрес объекта в БД. Но на практике мы можем сконструировать логическую часть OID. В таком случае объект все-равно будет найден (выбран из БД по неполному OID). Просто его поиск будет происходить медленнее, чем в представленном мною решении.
14 июн 05, 15:01    [1619357]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Мимо пробегал...

... в обеих таблицах существует условие PRIMARY KEY, что гарантирует, что добавляемые значения будут уникальными. Ес-но система тратит время на проверку этого условия....


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

Дело в том, что медлительность Sybase при записи элементов в таблицу ChildTable в значительной мере зависит от количества записей в таблице MainTable. Необходимость же (или отсутствие оной) проверки PK при записи новых элементов в таблицу ChildTable никак не может повлиять на указанную зависимость. Сам фактор траты ресурсов на проверку PK проявляется в весьма незначительном увеличении среднего времени записи новых 100000 элементов в таблицу ChildTable по мере роста объемов последней (чем больше элементов в таблице, тем больше времени уходит на проверку уникальности каждого нового элемента).
14 июн 05, 15:56    [1619557]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Alexey Rovdo

Я попробую доопределить еще один индекс и посмотрю как это скажется на производительности.


Доопредилил.
В наихудшем случае это приводит к увеличению времени сохранения объектов класса ChildTable на величину порядка 10 секунд на каждые 100000 объектов, т.е. ~100 секунд на каждый миллион. Никакого принципиального влияния на результаты тестирования это не оказывает (скажем полученное мною соотношение производительностей "75 раз" изменится в конкретном примере на "~60 раз").
14 июн 05, 16:09    [1619612]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Мимо пробегал...
Guest
Я, когда смотрю на листинги, то вижу, что время вставки в тбл. Child увеличивается по мере роста числа записей. Очень хорошо это видно на примере с 10 мл записей - первые 100000 вставляется за около секунды, последние 100000 - за 20 секунд. Насколько я понимаю, число записей в тбл. Primary не меняется. Другими словами, это замеделение не связано с числом записей в тбл. Primary. Интересно, если в таблице Child убрать PRIMARY KEY, ситуация сильно поменяется?
14 июн 05, 16:15    [1619629]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Foxi - Voxi
Guest
ASCRUS
Или Вы серьезно думаете, что мир можно уложить в ОО-модель и ее принципов хватит на все, про все и что если бы это поняли все, то настало светлое радостное будующее ?

Отнюдь. Я просто хочу сказать, что мне известны случаи, когда нужно было в конкретные сроки завершить разработку СУБД - комплекса, и ситуация была спасена именно переходом на ООСУБД. Проект Естественно, пришлось выложить денежку. Обратных случаев я не знаю. Вернее - знаю, когда из-за недопустипого медленного O/R маппинга пришлось вернуться к "традиционному сексу".

Естественно, масса подводных камней.
Во-первых, ОО - модели (в т.ч. для СУБД) как таковой не существует в природе. Во-вторых, даже уважаемой Versant продукты (Fast Objects *, к примеру) - не ОО - по крайней мере, в том виде, как бы мне хотелось. (Про средства O/R маппинга промолчу из-за известных мне и Вам тормозах при работе - это все от бедности.) Вся мощь ООСУБД проявляется именно при разработке приложений. И если Вы не работали с ними - то и говорить не о чем. Я говорю именно об ОО - проектировании БД с использованием OODB!

ASCRUS
Как то странно, что многие ОО-приверженцы думают, что те, кто проектирует БД на РСУБД делают это исключительно потому, что стары и ничего не понимают в ООП. Очень большое заблуждение, многие именно на нем и начинали с конца 80-х и начала 90-х, когда еще не было не то, что......

Можете назвать пример реализации ООСУБД 80-х годов, которую Вы использовали?

ASCRUS
Если посмотреть, то основная масса этих специалистов как раз сейчас на РСУБД и сидит.
...

... так ведь ничего другого и нет!

Попробуйте просто ради экперимента - возьмите реляционную модель "средней тяжести" и переведите ее в любую доступную Вам ООСУБД. Получилось? Получилось! (Или не получилось - т.к. нет скорее всего у Вас доступной ООСУБД). Ну, может, только триггеры/ХП переписать пришлось в терминах языка СУБД.
А теперь берем объектную модель соизмеримой сложности (ну, по количеству классов ~ количеству таблиц - хотя это не совсем, хм, верно) - и переведите ее в реляционную. Ну, и как Вам оно? Я скромно молчу про перевод реализации методов объектов в ХП/Триггеры.

Не говоря о времени разработки - объектная модель будет готова в 10 раз быстрее, т.к. Вы не будете думать о всяких глупостях, вроде организации уникальных индексов для первичных ключей и т.п.

Только вот попробовать Вам не на чем... Беда.

ЗЫ: Вы не обращайте внимания, это я не с Вами разговаривал.
14 июн 05, 16:18    [1619643]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Думаю это связано с исчерпанием памяти. На начальном этапе заполнения таблицы ChildTable весьма на мой взгляд эффективный механизм кэширования Sybase существенно ускоряет процесс. Но я проведу эксперимент и без PK.
14 июн 05, 16:20    [1619646]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 25 26 27 28 29 30 [31] 32 33 34   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить