Apa jenis sistem yang harus "ditingkatkan" daripada "ditingkatkan"?


12

Saya telah lama bertanya-tanya apakah ada sistem yang harus "meningkatkan" (ke server yang lebih kuat, lebih mahal) daripada "memperbesar" dengan dipecah di banyak server yang lebih kecil.

Apakah sistem seperti itu ada, dan jika demikian, adakah sesuatu yang khusus yang cenderung menyebabkan sistem perlu ditingkatkan, bukannya diperkecil? (Misalnya, mungkin transaksi basis data pengaduan ACID, atau persyaratan integritas data kuat lainnya membuat kebutuhan ini.)

Karena meningkatkan sepertinya akan membawa biaya perangkat keras yang jauh lebih tinggi daripada scaling out, sepertinya sesuatu yang ingin Anda hindari, jika mungkin, tetapi saya tidak yakin apakah itu selalu dapat dihindari atau tidak.

Jadi, apakah ada sistem yang tidak dapat ditingkatkan, dan harus ditingkatkan? Apa yang dapat menyebabkan ini, dan bagaimana Anda mengidentifikasi sistem seperti itu? (Apakah mereka secara umum memiliki beberapa kesamaan karakteristik yang mungkin membuat mereka lebih mudah diidentifikasi?)



7
Peningkatan seringkali jauh lebih mudah jika perangkat lunak Anda tidak dirancang untuk berkembang. Merancang ulang perangkat lunak itu mahal, atau tidak mungkin jika Anda tidak memiliki sumbernya, atau memiliki pengaruh terhadap pengembang.
Zoredache

Menulis sistem seperti itu adalah masalah yang sangat sulit. Terutama desain master / master yang bisa datang dan pergi di mana banyak master menulis ke catatan yang sama pada saat yang sama. Siapa yang menang?
Matt

3
Anda mungkin tertarik CAP Teorema . Pada dasarnya, sebuah layanan yang membutuhkan konsistensi dan ketersediaan seperti yang didefinisikan dalam teorema tidak akan mentolerir partisi. Kebanyakan persyaratan dunia nyata dapat mengorbankan konsistensi untuk konsistensi akhirnya (secara manual atau otomatis menangani ketidakkonsistenan setelah fakta) atau mengorbankan ketersediaan dengan menolak untuk memproses permintaan ketika beberapa peserta tidak tersedia. Oleh karena itu, sistem yang membutuhkan konsistensi absolut dan ketersediaan absolut pada dasarnya dipaksa untuk ditingkatkan.
Lie Ryan

1
Jika dengan "LAN andal" yang Anda maksudkan "tidak pernah mengalami kegagalan", maka Anda tidak mendesain untuk dunia nyata.
mfinni

Jawaban:


18

Saya terutama bekerja dengan aplikasi yang memiliki potensi skala horisontal nol . Meskipun berjalan di Linux, aplikasi, struktur data, dan persyaratan I / O memaksa saya untuk "meningkatkan" ke sistem yang semakin besar untuk mengakomodasi peningkatan beban kerja pengguna.

Banyak aplikasi lini bisnis dan transaksional yang lama memiliki kendala semacam ini. Itulah salah satu alasan saya menekankan bahwa fokus industri pada solusi cloud dan arsitektur skala web yang digerakkan DevOps mengabaikan persentase yang baik dari dunia komputasi.

Sayangnya, sistem peningkatan yang saya jelaskan benar - benar tidak menarik , sehingga industri cenderung mengabaikan nilai mereka atau mengurangi keterampilan yang dibutuhkan untuk mengatasi sistem yang besar dan kritis (misalnya ternak versus hewan peliharaan ).


1
"Hal termudah untuk dilakukan adalah melempar perangkat keras pada masalahnya." Tolong, Hukum Moore, jangan berhenti bekerja!
cjc

2
@ Demetri - Microsoft SQL Server adalah produk "profil paling tinggi" yang bisa saya pikirkan yang merupakan "peningkatan" khas daripada "skala keluar". Menskalakannya hampir tidak mungkin kecuali jika Anda memenuhi serangkaian kriteria yang sangat spesifik untuk replikasi gabungan.
Mark Henderson

3
Atau jika Anda dapat menguraikan solusi menjadi beberapa masalah. Misalnya, jangan menjalankan pelaporan terhadap basis data transaksi Anda; tekan replika yang berjalan di perangkat keras lain. \
mfinni

1
-1. Saya pikir Anda merindukan inti permasalahan. Masalah Anda tidak dipaksa diperkecil jika Anda dapat menulis ulang sistem untuk sistem skala keluar. Pertanyaan ini tentang sistem yang domain masalahnya adalah sehingga skala keluar tidak mungkin sama sekali bahkan ketika dirancang dari bawah ke atas.
Lie Ryan

1
@LieRyan Comprehension. Saya menyatakan bahwa aplikasi yang saya dukung tidak dapat ditingkatkan (ini seperti sistem basis data) ... bahkan jika dirancang ulang, karena kendala arsitektur.
ewwhite

8

Dari sudut pandang pengembang, saya dapat mengatakan bahwa hampir setiap mesin basis data arus utama tradisional di luar sana hanya dapat meningkatkan dan meningkatkan skala sangat banyak setelah dipikirkan.

Dalam beberapa tahun terakhir dengan kebutuhan skalabilitas yang lebih besar dan sistem yang sangat tersedia, ada upaya untuk membuat skala basis data yang ada. Tetapi karena desain dihambat oleh kode warisan, itu sangat melesat daripada mendasar untuk desain. Anda akan menemukan ini jika mencoba untuk skala sebagian besar mesin database terkenal. Menambahkan server slave bisa sangat sulit untuk diatur dan Anda akan melihat bahwa itu datang dengan keterbatasan yang signifikan, beberapa di antaranya mungkin memerlukan re-jigging tabel database Anda.

Sebagai contoh, kebanyakan dari mereka adalah master / (multi-) slave daripada desain multi-master. Dengan kata lain, Anda mungkin hanya memiliki seluruh server hanya duduk di sana dan tidak dapat memproses permintaan. Beberapa melakukannya, tetapi dengan keterbatasan ... misalnya hanya baca desain multi-slave. Jadi, Anda mungkin memiliki satu server yang melakukan penulisan dan yang lainnya menyediakan data hanya-baca. Anda akan melihat ketika Anda mengatur sistem ini, itu tidak selalu merupakan proses yang mudah dan sulit untuk bekerja dengan baik. Rasanya sangat banyak pada penambahan dalam banyak kasus.

Di sisi lain, ada beberapa mesin database yang lebih baru sedang dikembangkan dengan concurrency dan desain multi-master dari awal. NOSQL dan NewSQL adalah kelas desain baru.

Jadi sepertinya cara terbaik untuk mendapatkan kinerja yang lebih baik dari server SQL tradisional ditingkatkan! Sementara dengan NOSQL & NewSQL keduanya ditingkatkan & ditingkatkan.

Alasan tradisional sistem RDBMS digabungkan secara ketat adalah karena mereka semua membutuhkan pandangan yang konsisten dari data yang sama. Ketika Anda memiliki beberapa server yang menerima pembaruan untuk data yang sama dari klien yang berbeda, yang mana yang Anda percayai? Setiap metode yang berusaha untuk memastikan bahwa data konsisten melalui semacam mekanisme penguncian membutuhkan kerja sama dari server lain yang dapat merusak kinerja atau memengaruhi kualitas data karena data yang dibaca dari klien mungkin sudah ketinggalan zaman. Dan server perlu memutuskan di antara mereka sendiri data mana yang paling baru saat menulis ke catatan yang sama. Seperti yang Anda lihat itu adalah masalah kompleks yang dibuat lebih kompleks oleh kenyataan bahwa beban kerja tersebar di server dan bukan hanya di antara proses atau utas di mana akses ke data masih cukup cepat.


Bukankah Oracle RAC telah memberikan skala sejak 10g?
Dani_l

Memiliki. Tetapi kemudian memiliki RAC dan memiliki RAC yang bekerja dengan sempurna adalah dua hal yang berbeda - ini benar-benar membutuhkan perawatan khusus untuk tetap berjalan. Ini adalah desain yang bagus. Jika Anda membutuhkannya, Anda kemungkinan besar bersedia membayar harganya.
TomTom

Dan perhatikan sistem penyimpanan bersama yang dibutuhkan untuk Oracle RAC. Itu bisa menghadirkan masalah penskalaan tergantung pada bagaimana penerapannya.
Matt

7

Menurut pendapat saya demarkasi skala naik / turun ditentukan pada seberapa paralel alur kerja dapat, dan seberapa erat benang paralel perlu berkoordinasi satu sama lain.

Single Threaded
Untuk alasan apa pun, alur kerja ini hanya dapat bekerja dalam satu utas.

Satu utas berarti satu sistem berarti ditingkatkan untuk membuatnya berjalan lebih cepat.

Paralelisme yang berpasangan ketat
Ini adalah sistem multi-ulir di mana utas-utas tersebut harus saling terkait erat. Mungkin antar-proses-komunikasi harus sangat cepat, atau semua itu perlu dikelola melalui manajer memori tunggal. Sebagian besar sistem RDBMS adalah komputasi paralel semacam ini.

Untuk sebagian besar, sistem ini adalah yang meningkatkan skala lebih baik daripada keluar meskipun ada pengecualian. Misalnya, alur kerja yang akan berfungsi pada klaster gaya Sistem Gambar Tunggal , ruang memori tunggal tetapi latensi tinggi di antara utas, dapat membuat penskalaan lebih mudah. Tetapi sistem SSI seperti itu sangat sulit untuk dikerjakan sehingga sebagian besar insinyur hanya membuat kotak yang lebih besar.

Paralelisme berpasangan longgar
Ini adalah sistem multi-utas / proses di mana utas OK dengan latensi tinggi di antara satu sama lain. Atau tidak perlu berbicara satu sama lain sama sekali. Memperbesar penyajian web dan render-farm adalah contoh klasik dari sistem semacam ini. Sistem seperti ini jauh lebih mudah untuk dibuat lebih besar daripada paralelisme yang dipasangkan, itulah sebabnya ada banyak kegembiraan tentang gaya sistem ini.

Ini adalah gaya di mana skala keluar jauh lebih mudah.


Alasan RDBMS digabungkan secara ketat adalah karena mereka digabungkan dengan data. yaitu beberapa server yang mengakses sumber daya yang sama.
Matt
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.