Praktik / Pola terbaik untuk sinkronisasi data dua arah


52

Cukup sering dalam pekerjaan saya gagasan sinkronisasi data 2 arah antara sistem database muncul. Contoh klasik adalah dua sistem CRM yang sedikit berbeda (katakanlah, Raiser's Edge dan Salesforce) dan kebutuhan untuk memiliki sinkronisasi dua arah data Kontak di antara mereka.

Selain pertimbangan API, dengan anggapan Anda memiliki kunci bersama untuk disinkronkan, dan murni memikirkan algoritma / pola yang akan digunakan, ini adalah tugas yang sering dianggap remeh oleh non-teknologi.

Misalnya, Anda harus berhati-hati untuk:

  • Dapatkah Anda dengan mudah mendeteksi catatan mana yang telah berubah di kedua sistem (atau apakah Anda harus membandingkan semua catatan antara sistem untuk mendeteksi perubahan)
  • Jika Anda pergi untuk sinkronisasi sekali-setiap-N-jam, bagaimana menangani konflik di mana catatan yang sama berubah pada waktu yang kurang lebih sama pada kedua sistem
  • Jika Anda pergi untuk sinkronisasi waktu-nyata (yaitu pembaruan dalam satu sistem segera memicu pembaruan ke sistem lain) bagaimana menangani perbedaan dari waktu ke waktu karena bug atau sistem crash

Secara pribadi saya bisa memikirkan cara untuk mengatasi semua ini, tetapi saya bertanya-tanya apakah ada pola, literatur, atau praktik terbaik yang bisa saya lihat.


apa yang Anda gambarkan terdengar cukup dekat dengan sistem basis data Federated - apakah itu benar?
nyamuk

@gnat: Terima kasih atas tautannya, beberapa masalah serupa (misalnya, berurusan dengan heterogenitas), tetapi saya sedang berbicara tentang menyinkronkan subkumpulan data dari dua database otonom sedangkan yang tampaknya lebih tentang menciptakan pandangan yang sepenuhnya terintegrasi dari segala sesuatu di beberapa dbs.
codeulike

1
7 tahun kemudian, 50 suara naik tetapi hanya 1 jawaban yang layak. Harus ada beberapa pola sinkronisasi atau praktik terbaik di luar sana?
codeulike

Jawaban:


8

Ya, masalah yang sulit, mudah diremehkan. Dan bisa jadi banyak pekerjaan. Jika Anda menggunakan teknologi Microsoft, Anda mungkin ingin melihat Microsoft Sync Framework di sini dan di sini .


1
Terima kasih, itu menarik. Saya pernah mendengar tentang Ms Sync Framework tetapi tidak menyadari bahwa itu sangat digeneralisasi. Ini pada dasarnya adalah pola untuk menangani masalah sinkronisasi secara umum.
codeulike

2
Microsoft Sync Framework digantikan oleh Microsoft Sync Framework Toolkit.
Tomas Kubes

Saya frustrasi dengan dokumen, yang tidak begitu jelas, khusus untuk penyedia data ADO.NET Non SQL-Server, yang merupakan kasus saya. Selain itu, tempat kerja saya mencari sesuatu yang tidak memerlukan penambahan tabel infrastruktur / membuat perubahan dalam lingkungan Produksi. Jadi saya akan membuang yang ini.
Veverke

0

Ada banyak teori tentang sinkronisasi DB situs jarak jauh. Pertama mulai dengan INSERT. menangani yang ini mudah - karena Anda dapat membuat ID unik untuk setiap situs (misalnya inisial nama situs + ID (nomor): site_a_177 vs. site_b_53)

Jadi masukkan tidak boleh membuat konflik. masalahnya adalah pembaruan. Saya tidak percaya bahwa ada metode bukti kegagalan 100%, tetapi Anda dapat memulai pembaruan dengan "mengunci" catatan di DB jarak jauh, dan hanya setelah Anda mendapatkan pegangan - lanjutkan dengan pembaruan, dan selesaikan dengan menyinkronkan pembaruan dan baru kemudian lepaskan kunci.


1
Terima kasih, saya pikir Anda sedang berbicara tentang dbs terdistribusi dengan skema yang sama dan berurusan dengan transaksi terdistribusi. Saya lebih memikirkan skenario di mana kedua DB sepenuhnya otonom (misalnya mereka menetapkan id unik dengan cara yang sama sekali berbeda dan skema berbeda) tetapi Anda ingin menyinkronkan subkumpulan data di dalamnya.
codeulike

Sepertinya tidak ada konflik. Dalam hal ini seharusnya sangat sederhana - simpan saja "record-id terakhir" yang disinkronkan untuk setiap tabel dan lanjutkan dari sana.
alfasin
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.