MongoDB ерөнхийдөө зөв сонголт байсан уу?

Би үүнийг саяхан олж мэдсэн Red Hat нь хиймэл дагуулаас MongoDB дэмжлэгийг устгасан (Тэд лицензийн өөрчлөлтийн улмаас хэлж байна). Сүүлийн хэдэн жил MongoDB ямар аймшигтай вэ, хэн ч үүнийг хэзээ ч ашиглаж болохгүй гэсэн олон нийтлэлийг харсан болохоор энэ нь надад бодогдлоо. Гэхдээ энэ хугацаанд MongoDB илүү боловсронгуй бүтээгдэхүүн болсон. Юу болсон бэ? Бүх үзэн ядалт үнэхээр шинэ DBMS-ийн маркетингийн эхэн үеийн алдаанаас үүдэлтэй юу? Эсвэл хүмүүс зүгээр л MongoDB-г буруу газар ашиглаж байна уу?

Хэрэв та намайг MongoDB-г хамгаалж байгаа юм шиг санагдаж байвал уншина уу татгалзал нийтлэлийн төгсгөлд.

Шинэ чиг хандлага

Би програм хангамжийн салбарт миний хэлж чадахаас илүү олон жил ажилласан ч манай салбарт нөлөөлсөн чиг хандлагын өчүүхэн хэсгийг л олж мэдсэн хэвээр байна. Би 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain-ийн өсөлтийн гэрч болсон ... жагсаалт эцэс төгсгөлгүй юм. Жил бүр шинэ чиг хандлага гарч ирдэг. Зарим нь хурдан арилдаг бол зарим нь програм хангамжийг боловсруулах арга барилыг үндсээр нь өөрчилдөг.

Шинэ чиг хандлага бүр ерөнхий сэтгэл хөдлөлийг бий болгодог: хүмүүс онгоцон дээр үсрэх, эсвэл бусдын үүсгэсэн чимээ шуугианыг харж, олныг дагадаг. Энэ процессыг Gartner кодчилсон шуугианы мөчлөг. Хэдийгээр маргаантай байгаа ч энэ он цагийн хэлхээс нь технологид хэрэг болохоос нь өмнө юу тохиолдохыг ойролцоогоор дүрсэлдэг.

Гэхдээ үе үе шинэ инноваци гарч ирдэг (эсвэл энэ тохиолдолд хоёр дахь удаагаа гарч ирдэг) зөвхөн нэг тодорхой хэрэгжилтээс үүдэлтэй. NoSQL-ийн тухайд MongoDB гарч ирэн, солиорсон өсөлтөд ихээхэн нөлөөлсөн. MongoDB энэ чиг хандлагыг эхлүүлээгүй: үнэн хэрэгтээ интернетийн томоохон компаниуд их хэмжээний өгөгдлийг боловсруулахад асуудал үүсгэж эхэлсэн бөгөөд энэ нь харилцаа холбоогүй мэдээллийн сангуудыг буцааж авахад хүргэсэн. Нийт хөдөлгөөн нь Google-ийн Bigtable болон Facebook-ийн Кассандра зэрэг төслүүдээс эхэлсэн боловч MongoDB нь ихэнх хөгжүүлэгчид хандах боломжтой байсан хамгийн алдартай, хүртээмжтэй NoSQL мэдээллийн баазын хэрэгжилт болсон юм.

Тэмдэглэл: Та намайг баримт бичгийн өгөгдлийн санг багана хэлбэрийн өгөгдлийн сан, түлхүүр/утга хадгалах сан эсвэл NoSQL-ийн ерөнхий тодорхойлолтод хамаарах бусад олон төрлийн мэдээллийн сантай андуурч байна гэж бодож магадгүй. Мөн таны зөв. Гэвч тэр үед эмх замбараагүй байдал ноёрхсон. Хүн бүр NoSQL-д хэт автдаг, энэ нь хүн бүр болсон үнэхээр туйлын их шаардлагатай боловч олон хүн өөр өөр технологийн ялгааг олж хараагүй. Олон хүмүүсийн хувьд MongoDB болсон ижил утгатай NoSQL.

Мөн хөгжүүлэгчид түүн рүү дайрчээ. Аливаа асуудлыг шийдэхийн тулд ид шидээр масштабтай, бүдүүвчгүй мэдээллийн сангийн санаа нь маш сонирхолтой байсан. Ойролцоогоор 2014 онд MySQL, Postgres эсвэл SQL Server зэрэг харилцааны мэдээллийн баазыг жилийн өмнө ашиглаж байсан хаа сайгүй MongoDB мэдээллийн баазыг байрлуулж эхэлсэн бололтой. Учрыг нь асуухад та "энэ бол вэбийн цар хүрээ" гэсэн үгнээс "миний өгөгдөл маш сул бүтэцтэй, схемгүй мэдээллийн санд сайн нийцдэг" гэсэн хариултыг авч болно.

MongoDB болон ерөнхийдөө баримт бичгийн мэдээллийн сан нь уламжлалт харилцааны мэдээллийн сантай холбоотой хэд хэдэн асуудлыг шийддэг гэдгийг санах нь чухал.

  • Хатуу схем: Харилцааны өгөгдлийн сангийн хувьд, хэрэв танд динамикаар үүсгэгдсэн өгөгдөл байгаа бол та санамсаргүй "төрөл бүрийн" өгөгдлийн багана үүсгэх, өгөгдлийн бөөмүүдийг оруулах эсвэл тохиргоог ашиглахаас өөр аргагүй болно. EAV...энэ бүхэн мэдэгдэхүйц сул талуудтай.
  • Хэмжээ тогтооход хүндрэлтэй байна: Хэрэв нэг серверт тохирохгүй тийм их өгөгдөл байгаа бол MongoDB түүнийг олон машинд масштаблах боломжийг олгох механизмуудыг санал болгосон.
  • Нарийн төвөгтэй хэлхээний өөрчлөлтүүд: шилжилт хөдөлгөөн байхгүй! Харилцааны өгөгдлийн санд өгөгдлийн сангийн бүтцийг өөрчлөх нь асар том асуудал үүсгэдэг (ялангуяа маш их өгөгдөлтэй үед). MongoDB үйл явцыг ихээхэн хялбарчилж чадсан. Энэ нь үүнийг маш хялбар болгосон тул та зүгээр л явж байхдаа хэлхээг шинэчилж, маш хурдан хөдөлж болно.
  • Бичлэгийн гүйцэтгэл: MongoDB гүйцэтгэл, ялангуяа зөв тохируулагдсан үед сайн байсан. МонгоДБ-ын байнгын шүүмжлэлд өртдөг байсан хайрцагнаас гарсан тохиргоо хүртэл гүйцэтгэлийн гайхалтай үзүүлэлтүүдийг харуулсан.

Бүх эрсдэл чам дээр байна

MongoDB-ийн боломжит ашиг тус, ялангуяа зарим төрлийн асуудлын хувьд асар их байсан. Хэрэв та дээрх жагсаалтыг контекстийг ойлгоогүй, туршлагагүй уншвал MongoDB нь үнэхээр хувьсгалт DBMS юм шиг сэтгэгдэл төрүүлж магадгүй юм. Ганц асуудал бол дээр дурдсан ашиг тус нь хэд хэдэн анхааруулгатай байсан бөгөөд тэдгээрийн заримыг доор жагсаав.

Шударга байхын тулд 10gen/MongoDB Inc-д хэн ч байхгүй. Дараах нь үнэн биш гэж хэлэхгүй, эдгээр нь зүгээр л буулт юм.

  • Алдагдсан гүйлгээ: Гүйлгээ нь олон харилцааны мэдээллийн сангийн үндсэн шинж чанар юм (бүгд биш, гэхдээ ихэнх). Гүйлгээ гэдэг нь та хэд хэдэн үйлдлийг атомаар гүйцэтгэх боломжтой бөгөөд өгөгдөл нь тогтвортой байх болно гэсэн үг юм. Мэдээжийн хэрэг, NoSQL мэдээллийн баазтай бол гүйлгээ нь нэг баримт бичигт багтах эсвэл гүйлгээний семантикийг авахын тулд хоёр үе шаттай амлалтуудыг ашиглаж болно. Гэхдээ та энэ функцийг өөрөө хэрэгжүүлэх хэрэгтэй болно ... энэ нь хэцүү бөгөөд цаг хугацаа шаардсан ажил байж магадгүй юм. Мэдээллийн сан дахь өгөгдөл хүчин төгөлдөр бус төлөвт орж байгааг харах хүртлээ асуудал байгааг та ихэнхдээ ойлгодоггүй, учир нь үйл ажиллагааны атомын шинж чанарыг баталгаажуулах боломжгүй юм. Жич: MongoDB 4.0 өнгөрсөн жил гүйлгээг нэвтрүүлсэн боловч зарим хязгаарлалттай гэж олон хүн надад хэлсэн. Нийтлэлээс авсан мэдээлэл нь ижил хэвээр байна: технологи таны хэрэгцээнд хэр нийцэж байгааг үнэл.
  • Харилцааны бүрэн бүтэн байдал алдагдах (гадаад түлхүүрүүд): Хэрэв таны өгөгдөлд хамаарал байгаа бол тэдгээрийг аппликешнд ашиглах шаардлагатай болно. Эдгээр харилцааг хүндэтгэдэг өгөгдлийн сантай байх нь аппликешн, улмаар таны программистуудын ажилд ихээхэн хүчин чармайлт гаргах болно.
  • Өгөгдлийн бүтцийг ашиглах чадвар дутмаг: Хатуу схемүүд нь заримдаа том асуудал байж болох ч ухаалгаар ашиглавал өгөгдлийн сайн бүтцийг бий болгох хүчирхэг механизм юм. MongoDB зэрэг баримт бичгийн мэдээллийн сан нь схемийн гайхалтай уян хатан байдлыг хангадаг боловч энэхүү уян хатан байдал нь өгөгдлийг цэвэр байлгах үүрэг хариуцлагыг арилгадаг. Хэрэв та тэдэнд анхаарал тавихгүй бол таны хүлээгдэж буй хэлбэрээр хадгалагдаагүй өгөгдлийг тооцоолохын тулд програмдаа маш их код бичих болно. Энгийн Thread компанидаа бид байнга хэлдэг ... програм хэзээ нэгэн цагт дахин бичигдэх боловч өгөгдөл нь үүрд үлдэх болно. Тайлбар: MongoDB нь схем шалгахыг дэмждэг: энэ нь ашигтай боловч харилцааны мэдээллийн сантай ижил баталгаа өгдөггүй. Юуны өмнө, схемийн шалгалтыг нэмэх эсвэл өөрчлөх нь цуглуулгад байгаа өгөгдөлд нөлөөлөхгүй. Шинэ схемийн дагуу өгөгдлийг шинэчлэх эсэх нь танаас хамаарна. Энэ нь таны хэрэгцээнд хангалттай эсэхийг өөрөө шийдээрэй.
  • Төрөлх хайлтын хэл / хэрэгслийн экосистемийн алдагдал: SQL гарч ирсэн нь туйлын хувьсгал байсан бөгөөд түүнээс хойш юу ч өөрчлөгдөөгүй. Энэ бол гайхалтай хүчирхэг хэл боловч нэлээд төвөгтэй хэл юм. JSON фрагментуудаас бүрдсэн өгөгдлийн сангийн асуулгыг шинэ хэлээр бүтээх хэрэгцээг SQL-тэй ажиллаж байсан туршлагатай хүмүүс ухарсан том алхам гэж үздэг. IDE-ээс эхлээд тайлагнах хэрэгсэл хүртэл SQL өгөгдлийн сантай харьцдаг бүхэл бүтэн хэрэгслүүд байдаг. SQL-г дэмждэггүй өгөгдлийн сан руу шилжинэ гэдэг нь эдгээр хэрэгслүүдийн ихэнхийг ашиглах боломжгүй эсвэл тэдгээрийг ашиглахын тулд өгөгдлийг SQL рүү хөрвүүлэх шаардлагатай гэсэн үг бөгөөд энэ нь таны бодож байгаагаас илүү хэцүү байх болно.

MongoDB-д хандсан олон хөгжүүлэгчид харилцан ойлголцлыг огтхон ч ойлгодоггүй байсан бөгөөд ихэнхдээ үүнийг үндсэн мэдээллийн сан болгон суулгахын тулд толгойгоо гашилгадаг байв. Үүний дараа буцаж ирэх нь ихэвчлэн маш хэцүү байсан.

Юуг өөрөөр хийж болох байсан бэ?

Хүн бүр толгойгоо үсэрч, ёроолд нь цохисонгүй. Гэхдээ олон төслүүд MongoDB-г зүгээр л таарахгүй газар суулгасан бөгөөд тэд олон жилийн турш түүнтэй хамт амьдрах шаардлагатай болно. Хэрэв эдгээр байгууллагууд хэсэг хугацаа зарцуулж, технологийн сонголтоо сайтар бодож үзсэн бол олон хүмүүс өөр сонголт хийх байсан.

Хэрхэн зөв технологийг сонгох вэ? зэрэг технологийн үнэлгээний тогтолцоог бий болгох хэд хэдэн оролдлого хийсэн "Програм хангамжийн байгууллагуудад технологи нэвтрүүлэх хүрээ" и "Програм хангамжийн технологийг үнэлэх хүрээ", гэхдээ энэ нь шаардлагагүй төвөгтэй байдал юм шиг санагдаж байна.

Зөвхөн хоёр үндсэн асуулт асууснаар олон технологийг ухаалгаар үнэлж болно. Асуудал нь тэдэнд хариуцлагатай хариулж чадах хүмүүсийг хайж олох, хариултыг олоход цаг зарцуулж, өрөөсгөл ойлголтгүй байх явдал юм.

Хэрэв танд ямар нэгэн асуудал тулгараагүй бол танд шинэ хэрэгсэл хэрэггүй. Цэг.

Асуулт 1: Би ямар асуудлыг шийдэх гэж байна вэ?

Хэрэв танд ямар нэгэн асуудал тулгараагүй бол танд шинэ хэрэгсэл хэрэггүй. Цэг. Асуудлыг шийдэх арга замыг эрэлхийлж, дараа нь асуудал сэдэх шаардлагагүй. Хэрэв та шинэ технологи нь одоо байгаа технологиосоо хамаагүй илүү шийддэг асуудалтай тулгараагүй л бол энд хэлэлцэх зүйл алга. Хэрэв та бусад хүмүүс үүнийг ашиглаж байгааг харсан учраас энэ технологийг ашиглахаар бодож байгаа бол тэдэнд ямар асуудал тулгардаг талаар бодож, танд эдгээр асуудал байгаа эсэхийг асуу. Технологийг бусад хүмүүс ашиглаж байгаа тул хүлээн зөвшөөрөхөд хялбар байдаг тул танд ижил асуудал тулгарсан эсэхийг ойлгоход бэрхшээлтэй байдаг.

Асуулт 2: Надад юу дутагдаж байна вэ?

Энэ нь мэдээжийн хэрэг илүү хэцүү асуулт юм, учир нь та хуучин болон шинэ технологийн талаар сайтар ухаж, сайн ойлголттой байх хэрэгтэй. Заримдаа та түүгээр ямар нэгэн зүйл бүтээх эсвэл ийм туршлагатай хүнтэй болтол шинийг үнэхээр ойлгож чадахгүй.

Хэрэв танд аль нь ч байхгүй бол энэ хэрэгслийн үнэ цэнийг тодорхойлохын тулд хамгийн бага хөрөнгө оруулалтын талаар бодох нь зүйтэй. Мөн нэгэнт хөрөнгө оруулалт хийсэн бол шийдвэрээ буцаахад хэр хэцүү байх бол?

Хүмүүс үргэлж бүх зүйлийг сүйтгэдэг

Эдгээр асуултад аль болох шударгаар хариулахыг хичээхдээ нэг зүйлийг санаарай: чи хүний ​​мөн чанартай тэмцэх хэрэгтэй болно. Технологийг үр дүнтэй үнэлэхийн тулд хэд хэдэн танин мэдэхүйн гажуудлыг даван туулах шаардлагатай байдаг. Энд хэдхэн нь:

  • Олонхитой нэгдэхийн үр нөлөө - Түүний тухай бүгд мэддэг ч түүнтэй тулалдахад хэцүү хэвээр байна. Технологи нь таны бодит хэрэгцээнд нийцэж байгаа эсэхийг шалгаарай.
  • Шинэлэг нөлөө — Олон хөгжүүлэгчид удаан хугацаанд хамтран ажилласан технологио дутуу үнэлж, шинэ технологийн ашиг тусыг хэтрүүлэн үнэлэх хандлагатай байдаг. Энэ нь зөвхөн програмистууд биш, хүн бүр энэ танин мэдэхүйн гажуудалд өртөмтгий байдаг.
  • Эерэг шинж чанаруудын нөлөө - Бид тэнд байгаа зүйлийг харж, дутагдаж буй зүйлийг анзаарахгүй байх хандлагатай байдаг. Энэ нь шинэ технологитой хослуулан эмх замбараагүй байдалд хүргэж болзошгүй, учир нь та угаасаа шинэ технологийг хэт үнэлээд зогсохгүй түүний дутагдлыг үл тоомсорлодог..

Объектив үнэлгээ хийх нь тийм ч хялбар биш боловч танин мэдэхүйн үндсэн ойлголтыг ойлгох нь илүү оновчтой шийдвэр гаргахад тусална.

Хураангуй

Инноваци гарч ирэх бүрд хоёр асуултанд маш болгоомжтой хариулах ёстой.

  • Энэ хэрэгсэл нь жинхэнэ асуудлыг шийдэж чадах уу?
  • Бид харилцан тохиролцоог сайн ойлгож байна уу?

Хэрэв та энэ хоёр асуултанд итгэлтэйгээр хариулж чадахгүй бол хэдэн алхам ухраад бодоорой.

Тэгэхээр MongoDB зөв сонголт байсан уу? Мэдээж хэрэг тийм; Ихэнх инженерийн технологийн нэгэн адил энэ нь олон хүчин зүйлээс хамаардаг. Эдгээр хоёр асуултад хариулсан хүмүүсийн дунд олон хүн MongoDB-ээс ашиг хүртэж, ашиг хүртсээр байна. Ингэж амжаагүй хүмүүсийн хувьд та шуугиан дэгдээсэн мөчлөгийг даван туулах талаар үнэ цэнэтэй бөгөөд тийм ч хэцүү биш сургамж авсан гэж найдаж байна.

Хариуцлага

Би MongoDB-тэй хайрын болон үзэн ядалтын харилцаагүй гэдгээ тодруулмаар байна. MongoDB-ийн шийдвэрлэхэд хамгийн тохиромжтой тийм асуудал бидэнд байгаагүй. 10gen/MongoDB Inc гэдгийг би мэднэ. Эхэндээ маш зоримог байсан бөгөөд найдвартай бус өгөгдмөлүүдийг тогтоож, MongoDB-г хаа сайгүй (ялангуяа хакатон дээр) аливаа өгөгдөлтэй ажиллах бүх нийтийн шийдэл болгон сурталчилж байв. Энэ нь буруу шийдвэр байсан байх. Гэхдээ энэ нь энд тайлбарласан хандлагыг баталж байна: технологийн өнгөц үнэлгээгээр ч гэсэн эдгээр асуудлыг маш хурдан илрүүлж болно.

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх