วิธีที่ดีที่สุดในการนำเข้าข้อมูลจำนวนมากอีกครั้งด้วยเวลาหยุดทำงานน้อยที่สุด


11

ฉันต้องการนำเข้าประมาณ 500,000 รายการที่มีข้อมูลการค้นหา IP (การอ้างอิงแบบอ่านอย่างเดียว) ประมาณสัปดาห์ละครั้ง (คอลัมน์ int / bigint เพียงสามครั้ง)

ฉันไม่ต้องการกังวลเกี่ยวกับการรวมข้อมูลกับตารางที่มีอยู่ฉันต้องการล้างข้อมูลเก่าและนำเข้าใหม่

แบบสอบถามที่ใช้งานได้ดีในการเรียกใช้ข้อมูลจะยังคงทำงานต่อไป (เราไม่ได้รับสิ่งเหล่านี้จำนวนมากและเป็นที่ยอมรับสำหรับพวกเขาที่จะทำงานช้าลงเล็กน้อยในขณะที่การนำเข้าเกิดขึ้น แต่ต้องเพิ่มขึ้นทุกวันตลอด 24 ชั่วโมง หมดเวลา "ไม่ใช่ตัวเลือก)

สิ่งที่พยายามจนถึงตอนนี้

SSIS: ฉันได้สร้างแพ็คเกจ SSIS ที่ตัดทอนตารางและการนำเข้าออก - ใช้เวลาประมาณ 30 วินาทีในการเรียกใช้ (ยาวเกินไปจริง ๆ )

ตารางชั่วคราว: การนำเข้าสู่ตารางชั่วคราวการตัดและคัดลอกข้ามนั้นใช้เวลาประมาณ 30 วินาที

BCP: การนำเข้าจำนวนมากก็ค่อนข้างช้าเกินไป (ด้วยเหตุผลบางอย่างมันช้ากว่า SSIS (แม้ว่าจะไม่มีดัชนีที่จะรักษาไว้) - ฉันคิดว่ามันเป็นเรื่องเกี่ยวกับการทำธุรกรรม char-> int / bigint: /

โต๊ะกระจก ดังนั้นในขณะนี้ฉันสงสัยเกี่ยวกับการอ่านตารางผ่านมุมมองนำเข้าข้อมูลลงในตารางกระจกและเปลี่ยนมุมมองให้ชี้ไปที่ตารางนี้ ... ดูเหมือนว่ามันจะเร็ว แต่ดูเหมือนว่าเล็ก บิตแฮ็คกับฉัน

ดูเหมือนว่ามันจะเป็นปัญหาที่พบบ่อย แต่ฉันไม่สามารถหาแนวทางปฏิบัติที่แนะนำได้

ขอบคุณ

คำตอบ:


13

โซลูชันที่ฉันเคยใช้ในอดีต (และแนะนำที่นี่และใน StackOverflow มาก่อน) คือการสร้างสกีมาเพิ่มเติมสองรายการ:

CREATE SCHEMA shadow AUTHORIZATION dbo;
CREATE SCHEMA cache  AUTHORIZATION dbo;

ตอนนี้สร้างเลียนแบบตารางของคุณในcacheสคีมา:

CREATE TABLE cache.IPLookup(...columns...);

ตอนนี้เมื่อคุณทำการสวิตช์ของคุณ:

TRUNCATE TABLE cache.IPLookup;
BULK INSERT cache.IPLookup FROM ...;

-- the nice thing about the above is that it doesn't really
-- matter if it takes one minute or ten - you're not messing
-- with a table that anyone is using, so you aren't going to
-- interfere with active users.


-- this is a metadata operation so extremely fast - it will wait
-- for existing locks to be released, but won't block new locks
-- for very long at all:

BEGIN TRANSACTION;
  ALTER SCHEMA shadow TRANSFER    dbo.IPLookup;
  ALTER SCHEMA dbo    TRANSFER  cache.IPLookup;
COMMIT TRANSACTION;


-- now let's move the shadow table back over to
-- the cache schema so it's ready for next load:

ALTER SCHEMA cache TRANSFER shadow.IPLookup;
TRUNCATE TABLE cache.IPLookup; 

-- truncate is optional - I usually keep the data
-- around for debugging, but that's probably not
-- necessary in this case.

สิ่งนี้จะยุ่งยากกว่านี้หากคุณมีคีย์ต่างประเทศและการพึ่งพาอื่น ๆ (เนื่องจากคุณอาจต้องวางและสร้างใหม่อีกครั้ง) และแน่นอนว่ามันจะทำให้สถิติไม่ถูกต้องทั้งหมดและในทางกลับกันอาจส่งผลกระทบต่อแผน สิ่งที่สำคัญที่สุดคือการได้รับข้อมูลที่ถูกต้องต่อหน้าผู้ใช้ของคุณโดยมีการหยุดชะงักน้อยที่สุดซึ่งอาจเป็นแนวทางในการพิจารณา


ขอขอบคุณอีกทางเลือกที่น่าสนใจ - ฉันคิดว่าคำสั่งสองคำสั่งสุดท้ายไม่ถูกต้องควรย้ายเงาไปไว้ที่แคชและตัดแคช ฉันสงสัยว่าสามารถใช้คำพ้องความหมายได้หรือไม่
ทำเครื่องหมาย

คุณพูดถูก ฉันไม่แน่ใจเหมือนกันว่าคำพ้องความหมายจะดีขึ้นอย่างไรฉันคิดว่านั่นก็เป็นแนวทางเช่นกัน - มีมุมมองที่ชี้ไปที่คำพ้องความหมายและเปลี่ยนคำพ้องความหมายพื้นฐานในธุรกรรมเมื่อคุณเติมรุ่นอื่น โดยส่วนตัวฉันพบสิ่งนี้ดีขึ้นเล็กน้อย - เมื่อคุณทำการสืบค้น dbo.IPLookup คุณรู้ว่านั่นคือตาราง "ปัจจุบัน" โดยไม่ต้องไล่ล่ามุมมองและคำพ้องความหมาย
Aaron Bertrand

FYI ฉัน blogged เกี่ยวกับเรื่องนี้ในรายละเอียดเพิ่มเติมในสัปดาห์นี้: sqlperformance.com/2012/08/t-sql-queries/…
Aaron Bertrand
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.