بك جدول با ركورد چند صد ميليوني

[behrouzlo]

ما جدولي داريم كه تعداد ركوردهاي آن طي 2 سال به چند ميليون مي رسه، براي بالا بردن كارائي عمليات در روي اين جدول چه راهكارهاي در ورژن 2005 يا 2008 وجود داره؟
البته فكر كنم يكي از راههاي پارتشين بندي جدول باشه كه البته من اين گزينه را توي يك جدول با ركورد چند ده ميليوني تست كردم، حتي نتيجه بدتر از يك جدولي بود كه پارتشين بندي نشده بود. آيا براي پارتشين بندي نياز به تنظميات خاص روي سرور هست يا ...؟
فقط قضيه خيلي حياتي!

[AminSobati]

پارتیشن بندی باعث کاهش سرعت نباید بشه ولی نحوه انجام این کار و همچنین کوئری های شما بسیار حائز اهمیت هستند

[behrouzlo]

من از نحوه انجام كار پارتشين بندي مطمئن هستم، چون از روي منابع مختلف نحوه انجام كار را بررسي كردم و از صحت انجام كار خودم تقريبا مطمئن هستم.
ولي وقتي من كوئري را روي دو جدول مشابه كه پارتشين بندي شده و ديگري پارتشين بندي نشده است اجرائ مي كنم تقريبا در زمان يكسان و حتي در بعضي از موارد جدول عادي با اختلاف يكي و دو ثانيه زودتر جواب مي دهد.
مگر نبايد وقتي من داده اي را در بازه خاص جستجو مي كنم فقط پارتشين مربوط به آن بايد خوانده شود و يا وقتي داده ها روي پارتشين مختلف هستند براي هر پارتشين نخي جداگانه ايجاد شود؟ پس چرا اين اتفاق رخ مي دهد.
روش خاص ديگري را شما پيشنهاد نمي كنيد؟
با تشكر

[AminSobati]

از اجرای هر دو حالت Execution Plan بگیرین و Save کنین. اگر بفرستین میشه بررسی کرد

[behrouzlo]

من Execution Plan را بررسي كردم ولي در Index Seek گزينه Partitioned نمايش داده نمي شود فكر كنم به معني اين باشه كه اين گزينه False است كه نمايش داده نمي شود. فقط در مورد كزينه RID Look Up گزينه Partitioned وجود دارد و ساير اطلاعاتش با محدوده هاي پارتشين بندي ما مطابقت مي كنه.
من فايل XML را ارسال مي كنم

[behrouzlo]

من فايل هاي مربوط به Execution Plan مربوط به هر دو جدول را ارسال كردم. ببينيد كجاي كار مي لنگد.:عصبانی:
با تشكر

[behrouzlo]

مطالب بالا را ناديده بگيريد. در سايت MSDN مقاله اي با عنوان Query Processing Enhancements on Partitioned Tables and Indexes (http://msdn.microsoft.com/en-us/library/ms345599.aspx)
مي باشيد كه در انتهاي آن يك مثال قرار داده شده است. من اين اسكريپت را اجرا كردم و دقيقا مشابهي جدولي را كه در ديتابيسي كه ايجاد كرده بودم ايجاد كردم ولي بدون پارتشين بندي. كوئري كه در انتهاي مثال نوشته شده بود روي هر دو جدول اجرا كردم. اختلاف زماني بالاي 10 دقيقه بود.
مي توانيد به مقاله مراجعه كنيد و مثال را اجرا كنيد يا من اسكريپت همين مثال را اينجا قرار مي دهيم شما نيز مثل من عمل كنيد. و نتيجه را مقايسه كنيد.
مثل اينكه قضيه پارتشين بندي خودش مي لنگه.
فقط خواهشا تست كنيد تا به يك نتيجه برسيم. اسكريپت را اجرا كنيد و يك جدول مشابه جدول موجود در ژايگاه داده بسازيد با همان داده ها و مقايسه كنيد كوئري خود مثال روي هر دو جدول

[AminSobati]

دوست عزیزم من اسکریپت شما رو اجرا نکردم ولی متوجه نشدم منظورتون از لنگیدن چیه.
من اسکریپت خودم رو براتون میگذارم، میتونین نتایج کوئری های آخر رو از نظر Cost با هم مقایسه کنید.
به یاد داشته باشید پارتیشن بندی تحلیل زیادی قبلش نیاز داره.



use Northwind
go

-- Partitioned table
select * into Orders2 from orders
-- Non Partitioned table
select * into Orders3 from orders



------
alter database northwind
add filegroup fg96
go
alter database northwind
add filegroup fg97
go
alter database northwind
add filegroup fg98
go
alter database northwind
add filegroup fg99
go
alter database northwind
add file (name=Data96,filename='c:\Data96.ndf') to filegroup fg96
go
alter database northwind
add file (name=Data97,filename='c:\Data97.ndf') to filegroup fg97
go
alter database northwind
add file (name=Data98,filename='c:\Data98.ndf') to filegroup fg98
go
alter database northwind
add file (name=Data99,filename='c:\Data99.ndf') to filegroup fg99
go

------
CREATE PARTITION FUNCTION PF1 (DATETIME)
AS RANGE LEFT
FOR VALUES('19961231 23:59:59:997','19971231 23:59:59:997','19981231 23:59:59:997')
GO
------
CREATE PARTITION SCHEME PS1
AS PARTITION PF1
TO (fg96,fg97,fg98,fg99)



alter table Orders2
alter column OrderDate datetime not null
go

alter table Orders3
alter column OrderDate datetime not null
go

alter table Orders2
add constraint ix1 primary key clustered (orderid,orderdate) on ps1(orderdate)
go

alter table Orders3
add constraint ix2 primary key clustered (orderid,orderdate)


-- تست تاثیرگذاری پارتیشن

select * from orders2 where orderdate > '1998'
select * from orders3 where orderdate > '1998'

select * from orders2 where orderdate
between '19970101 00:00:00:000' and '19971231 23:59:59:997'
select * from orders3 where orderdate
between '19970101 00:00:00:000' and '19971231 23:59:59:997'

select * from orders2 where orderdate < '19961231 23:59:59:997'
select * from orders3 where orderdate < '19961231 23:59:59:997'




------------- CLEAN UP
drop table orders2
go
drop table orders3
go
drop partition scheme ps1
go
drop partition function pf1
go
alter database northwind
remove file data96
go
alter database northwind
remove file data97
go
alter database northwind
remove file data98
go
alter database northwind
remove file data99
go
alter database northwind
remove filegroup fg96
go
alter database northwind
remove filegroup fg97
go
alter database northwind
remove filegroup fg98
go
alter database northwind
remove filegroup fg99
go

[behrouzlo]

در ابتدا بخاطر توجهتان تشكر مي كنم. من مثال شما را اجرا كردم و مشاهده كردم كه هزينه عمليات كمتر است. ولي لطفا اگر فرصت كرديد شما اين اسكريپت را اجرا كنيد و نتيجه را بخصوص از لحاظ زماني مقايسه كنيد، اصلا قابل قبول نيست.
مگر نبايد سرعت عمليات با پارتشين بندي افزايش بيابد؟ چون گفتم مسئله زمان مشكل اصلي ما است.

[behrouzlo]

چي شد؟
يعني اينكه من منصرف بشم

[AminSobati]

دوست عزیزم Partitioning زمانی موثر واقع میشه که هر پارتیشن شما روی دیسک جداگانه باشه تا درخواست کاربرها هم با دیسکهای مختلف درگیر بشه. قرار دادن همه پارتیشن ها در یک دیسک چه منفعتی میتونه داشته باشه؟

[behrouzlo]

من حرف شمار را قبول مي كنم، نكته اي كه هميشه براي مشاهده كارائي پارتشين بندي تاكيده شده است ذخيره پارتشين ها روي ديسك يا داريو جداگانه است.
ولي باز وقتي كه روي يك ديسك و فايل گروههاي مختلف هستند از لحاظ تئوري بايد سريعتر داده ها بار گذاري شوند. شما كه اين را قبول مي كنيد.
حالا من گفتم كه تاكيدي زيادي روي پارتشين بندي ندارم اگر راه حلي ديگر يا پيشنهادي براي بالا بردن كارائي داريد لطفا ما را بي نصيب نگذاريد.
با تشكر

[AminSobati]

همه چیز بستگی به Query شما داره. و اینکه آیا ایندکس نیاز هست استفاده بشه یا خیر. طبعا Scan کردن یک پارتیشن سریعتر از Scan کردن کل جدول هست، ولی باید رفتار Query Processor رو بررسی کرد که آیا اونطور که ما حدس میزنیم کوئری رو اجرا کرده یا خیر.

[behrouzlo]

ايندكس كردن روي داده هاي بزرگ منابع زيادي از سيستم را مصرف مي كنه، اينطور نيست؟

[AminSobati]

بله، ولی یک بار ساخته میشه، برای همیشه