Би нэг техникийн түүхийг хэлье.
Олон жилийн өмнө би түүнд суулгасан хамтын ажиллагааны шинж чанаруудтай програм боловсруулж байсан. Энэ нь анхны React болон CouchDB-ийн бүрэн боломжийг ашигласан хэрэглэгчдэд ээлтэй туршилтын стек байсан юм. Энэ нь JSON-ээр дамжуулан бодит цаг хугацаанд өгөгдлийг синхрончлогдсон . Үүнийг компанийн дотоодод ашиглаж байсан боловч бусад салбарт өргөн хэрэглээний боломж, боломж нь тодорхой байсан.
Энэ технологийг боломжит үйлчлүүлэгчдэд зарах гэж оролдох үед бид гэнэтийн саад бэрхшээлтэй тулгарсан. Демо видеон дээр манай технологи маш сайн харагдаж, ажиллаж байсан, ямар ч асуудал байхгүй. Видео нь яг яаж ажилладагийг харуулсан бөгөөд юу ч дуурайгаагүй. Бид програмыг ашиглах бодит хувилбарыг гаргаж, кодлосон.
Үнэн хэрэгтээ энэ нь асуудал болсон. Манай демо нь бусад хүмүүс өөрсдийн программыг дуурайдаг шиг ажилладаг. Тодруулбал, том хэмжээний медиа файл байсан ч мэдээллийг А-аас Б руу шууд шилжүүлсэн. Нэвтэрсэний дараа хэрэглэгч бүр шинэ оруулгуудыг харсан. Уг програмыг ашигласнаар тосгоны хаа нэгтээ интернетийн холболт тасарсан байсан ч өөр өөр хэрэглэгчид ижил төсөл дээр тодорхой хамтран ажиллах боломжтой байв. Энэ нь After Effects-д тайрагдсан аливаа бүтээгдэхүүний видеон дээр шууд илэрхийлэгддэг.
Дахин сэргээх товчийг хүн бүр мэддэг байсан ч биднээс бүтээхийг хүссэн вэб програмууд нь ихэвчлэн өөрсдийн хязгаарлалттай байдаг гэдгийг хэн ч ойлгодоггүй. Хэрэв тэд шаардлагагүй бол хэрэглэгчийн туршлага огт өөр байх болно. Тэд ихэвчлэн ярилцаж буй хүмүүстээ зориулж тэмдэглэл үлдээх замаар "чатлах" боломжтой гэдгээ анзаарсан тул энэ нь жишээлбэл Slack-ээс юугаараа ялгаатай болохыг гайхаж байв. Өө!
Өдөр тутмын синхрончлолын дизайн
Хэрэв та програм хангамж хөгжүүлж байсан туршлагатай бол ихэнх хүмүүс интерфэйсийн зургийг хараад, үүнтэй харьцахдаа юу хийхээ ойлгох боломжгүй гэдгийг санах нь сэтгэл түгшээсэн байх ёстой. Програмын дотор юу болж байгааг дурдахгүй өнгөрч болохгүй. Үүнийг мэд болно юу тохиолдох нь юу болохгүй, юу болох ёсгүйг мэдсэний үр дүн юм. Үүнийг шаарддаг Програм хангамж нь зөвхөн юу хийдэг төдийгүй түүний бие даасан хэсгүүд хоорондоо хэрхэн уялдаж, хэрхэн харилцаж байгааг харуулдаг.
Үүний сонгодог жишээ бол хэрэглэгч a руу ширтэх явдал юм spinner.gif, ажил хэзээ дуусах бол гэж гайхаж байна. Процесс гацсан байж магадгүй бөгөөд gif дэлгэцээс хэзээ ч алга болохгүй гэдгийг хөгжүүлэгч ойлгох байсан. Энэ хөдөлгөөнт дүрс нь ажлын гүйцэтгэлийг дуурайдаг боловч түүний төлөвтэй холбоогүй юм. Ийм тохиолдолд зарим техникчид нүдээ эргэлдүүлэх дуртай бөгөөд хэрэглэгчдийн төөрөгдөл хэр их байгааг гайхдаг. Гэсэн хэдий ч тэдний хэд нь эргэдэг цаг руу чиглүүлж, энэ нь үнэхээр хөдөлгөөнгүй гэж хэлж байгааг анзаараарай?
Энэ бол бодит цагийн үнэ цэнийн мөн чанар юм. Өнөө үед бодит цагийн мэдээллийн сангууд маш бага ашиглагдаж байгаа бөгөөд олон хүмүүс тэднийг сэжиглэж үздэг. Эдгээр мэдээллийн сангуудын ихэнх нь NoSQL хэв маягт тулгуурладаг тул ихэнхдээ мартагдсан Mongo-д суурилсан шийдлүүдийг ашигладаг. Гэсэн хэдий ч миний хувьд энэ нь CouchDB-тэй ажиллахад таатай байхаас гадна зарим хүнд сурталтнаас илүү мэдээллээр дүүргэж чадах бүтэц зохион бүтээхэд суралцах гэсэн үг юм. Би цагаа илүү сайн ашиглаж байна гэж бодож байна.
Гэхдээ энэ нийтлэлийн жинхэнэ сэдэв бол миний өнөөдрийн хэрэглэж буй зүйл юм. Сонголтоор биш, харин хайхрамжгүй, харалган хэрэгжүүлсэн компанийн бодлогоос болж. Тиймээс би Google-ийн бодит цагийн мэдээллийн сангийн хоёр бүтээгдэхүүнийг бүрэн шударга, шударга бус харьцуулах болно.
Хоёулангийнх нь нэрэнд Гал гэдэг үг бий. Нэг зүйлийг би маш их санаж байна. Миний хувьд хоёр дахь зүйл бол өөр төрлийн гал юм. Би тэдний нэрийг хэлэх гэж яарахгүй байна, учир нь би хэлэх юм бол бид эхний том асуудал болох нэрстэй тулгарах болно.
Эхнийх нь гэж нэрлэгддэг Firebase бодит цагийн мэдээллийн сан, хоёрдугаарт - Firebase Cloud Firestore. Аль аль нь үйлдвэрлэсэн бүтээгдэхүүн юм Firebase багц Google. Тэдний API-г тус тусад нь нэрлэдэг firebase.database(…) и firebase.firestore(…).
Учир нь ийм зүйл болсон Бодит цагийн мэдээллийн сан - энэ бол зүгээр л эх хувь Функц 2014 онд Google-ээс худалдаж авахаас өмнө. Дараа нь Google зэрэгцээ бүтээгдэхүүн болгон бүтээхээр шийдсэн хуулбар Firebase нь том өгөгдлийн компанид суурилсан бөгөөд үүнийг үүлтэй Firestore гэж нэрлэсэн. Та одоохондоо андуураагүй гэж найдаж байна. Хэрэв та андуурсан хэвээр байгаа бол санаа зовох хэрэггүй, би өөрөө нийтлэлийн энэ хэсгийг арван удаа дахин бичсэн.
Учир нь та зааж өгөх хэрэгтэй Функц Firebase асуултанд, мөн Firestore Firebase-ийн талаархи асуултанд, ядаж хэдэн жилийн өмнө Stack Overflow дээр ойлгох хэрэгтэй.
Хэрэв програм хангамжийн нэршлийн хамгийн муу туршлагын шагнал байсан бол энэ нь өрсөлдөгчдийн нэг байх нь гарцаагүй. Эдгээр нэрсийн хоорондох Хаммингийн зай нь маш бага тул хуруугаараа нэг нэрийг бичдэг туршлагатай инженерүүдийг хүртэл толгой нь өөр нэрийг бодож эргэлздэг. Эдгээр нь бүтэлгүйтсэн сайн санааны төлөвлөгөө юм; тэд мэдээллийн сан шатах болно гэсэн зөгнөлийг биелүүлсэн. Тэгээд ч би огт тоглоогүй. Энэ нэрний схемийг гаргаж ирсэн хүн цус, хөлс, нулимс дуслуулсан.
Пиррикийн ялалт
Firestore гэж нэг нь бодох байх солих Firebase, түүний дараагийн үеийн удам, гэхдээ энэ нь төөрөгдүүлэх болно. Firestore нь Firebase-ийг орлуулахад тохиромжгүй. Эндээс хэн нэгэн сонирхолтой бүх зүйлийг хайчилж аваад бусад ихэнхийг нь янз бүрээр будлиулсан бололтой.
Гэсэн хэдий ч, хоёр бүтээгдэхүүнийг хурдан харах нь таныг төөрөлдүүлж магадгүй юм: тэд үндсэндээ ижил API-ууд, тэр ч байтугай нэг мэдээллийн сангийн сессээр дамжуулан ижил зүйлийг хийдэг бололтой. Ялгаанууд нь нарийн бөгөөд зөвхөн өргөн хүрээний баримт бичгийг сайтар харьцуулан судалснаар илэрдэг. Эсвэл та Firebase дээр төгс ажилладаг кодыг Firestore-тэй ажиллахын тулд порт хийх гэж оролдох үед. Тэр ч байтугай та бодит цаг хугацаанд хулганаар чирэх, буулгахыг оролдох үед мэдээллийн сангийн интерфейс асдаг болохыг олж мэдсэн. Би давтан хэлье, би тоглоогүй.
Firebase клиент нь өөрчлөлтийг буфер болгож, сүүлийн бичих үйлдэлд тэргүүлэх ач холбогдол өгдөг шинэчлэлтүүдийг автоматаар дахин оролддог утгаараа эелдэг ханддаг. Гэсэн хэдий ч Firestore нь нэг секундэд нэг баримт бичигт 1 бичих үйлдлийг хийх хязгаартай бөгөөд энэ хязгаарыг сервер хэрэгжүүлдэг. Түүнтэй ажиллахдаа үүнийг тойрон гарах арга замыг хайж, програмаа бүтээх гэж оролдож байсан ч шинэчлэлтийн хурд хязгаарлагчийг хэрэгжүүлэх нь танд хамаарна. Өөрөөр хэлбэл, Firestore бол бодит цагийн үйлчлүүлэгчгүй, API ашигладаг бодит цагийн мэдээллийн сан юм.
Эндээс бид Firestore-ийн raison d'être-ийн анхны шинж тэмдгүүдийг харж эхэлж байна. Миний буруу байж магадгүй, гэхдээ Google-ийн удирдлагад байсан хэн нэгэн худалдан авалтын дараа Firebase-г хараад “Үгүй ээ, бурхан минь, үгүй. Үүнийг хүлээн зөвшөөрөх боломжгүй. Зүгээр л миний удирдлаган дор биш."
Тэрээр танхимаасаа гарч ирээд:
"Нэг том JSON баримт уу? Үгүй Та өгөгдлийг тусдаа баримт бичиг болгон хувааж, тус бүр нь 1 мегабайтаас ихгүй хэмжээтэй байх болно."
Ийм хязгаарлалт нь хангалттай урам зоригтой хэрэглэгчийн баазтай анхны тулгарах үед даван туулахгүй байх шиг байна. гэдгийг та мэднэ. Жишээлбэл, ажил дээрээ бид нэг хагас мянга гаруй илтгэл тавьдаг бөгөөд энэ нь бүрэн хэвийн үзэгдэл юм.
Энэхүү хязгаарлалтын тусламжтайгаар та мэдээллийн сан дахь нэг "баримт бичиг" нь хэрэглэгчийн баримт гэж нэрлэж болох объекттой төстэй биш гэдгийг хүлээн зөвшөөрөхөөс өөр аргагүй болно.
"Бусад элементүүдийг рекурсив агуулж болох массивуудын массив уу? Үгүй Массивууд нь Бурханы хүссэнээр зөвхөн тогтмол урттай объект эсвэл тоонуудыг агуулна."
Хэрэв та GeoJSON-ыг Firestore-доо оруулна гэж найдаж байсан бол энэ боломжгүй гэдгийг ойлгох болно. Нэг хэмжээст биш юу ч хүлээн зөвшөөрөгдөхгүй. Танд Base64 ба/эсвэл JSON доторх JSON таалагдана гэж найдаж байна.
"JSON HTTP, тушаалын мөрийн хэрэгсэл эсвэл админ самбараар импортлох, экспортлох уу? Үгүй Та зөвхөн Google Cloud Storage руу өгөгдөл экспортлох, импортлох боломжтой. Одоо тэгж нэрлээд байгаа юм байх даа. Би "та" гэж хэлэхэд би зөвхөн Төслийн эзэмшигчийн үнэмлэхтэй хүмүүст хандаж байна. Бусад хүн бүр очиж тасалбар үүсгэж болно."
Таны харж байгаагаар FireBase өгөгдлийн загварыг тайлбарлахад хялбар байдаг. Энэ нь JSON түлхүүрүүдийг URL замтай холбосон нэг том JSON баримтыг агуулдаг. Хэрэв та хамт бичвэл HTTP PUT в / FireBase нь дараах байдалтай байна.
{
"hello": "world"
}
Нь GET /hello буцаж ирнэ "world". Үндсэндээ энэ нь таны бодож байсан шиг ажилладаг. FireBase объектуудын цуглуулга /my-collection/:id JSON толь бичигтэй тэнцэнэ {"my-collection": {...}} язгуурт, агуулгыг нь авах боломжтой /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Хэрэв оруулга бүр нь мөргөлдөхгүй ID-тай бөгөөд систем нь стандарт шийдэлтэй бол энэ нь маш сайн ажилладаг.
Өөрөөр хэлбэл, мэдээллийн сан нь 100% JSON(*) нийцтэй бөгөөд CouchDB гэх мэт HTTP-тэй маш сайн ажилладаг. Гэхдээ үндсэндээ та үүнийг вэб залгуур, зөвшөөрөл, захиалгыг хийсвэрлэдэг бодит цагийн API ашиглан ашигладаг. Админ самбар нь бодит цагийн засварлах болон JSON импорт/экспортын аль алиныг нь хоёуланг нь хийх боломжтой. Хэрэв та код дээрээ ижил зүйлийг хийвэл нөхөөс болон ялгавартай JSON нь байнгын төлөвтэй ажиллах ердийн даалгаврын 90% -ийг шийддэг гэдгийг ойлгох үед тусгайлсан код ямар их үрэгдэж байгааг та гайхах болно.
Firestore өгөгдлийн загвар нь JSON-той төстэй боловч зарим чухал зүйлээрээ ялгаатай. Массив дотор массив байхгүй талаар би аль хэдийн дурдсан. Дэд цуглуулгуудын загвар нь тэдгээрийг агуулсан JSON баримтаас тусад нь нэгдүгээр зэрэглэлийн ойлголтууд байх ёстой. Үүний тулд бэлэн цуваа байхгүй тул өгөгдлийг олж авах, бичихийн тулд тусгай кодын зам шаардлагатай. Өөрийнхөө цуглуулгыг боловсруулахын тулд та өөрийн скрипт, хэрэгслийг бичих хэрэгтэй. Админ самбар нь зөвхөн нэг талбарт жижиг өөрчлөлт хийх боломжийг олгодог бөгөөд импорт/экспорт хийх боломж байхгүй.
Тэд бодит цагийн NoSQL мэдээллийн санг авч, автоматаар нэгдэх, JSON бус тусдаа багана бүхий удаан SQL биш болгон хувиргасан. GraftQL шиг зүйл.
Халуун Java
Хэрэв Firestore нь илүү найдвартай, өргөтгөх боломжтой байх ёстой байсан бол энгийн хөгжүүлэгчид FireBase-ийг сонгохоос илүү найдвартай шийдэл гаргахгүй байх нь хачирхалтай юм. Grumpy Database Administrator-д хэрэгтэй програм хангамж нь тухайн бүтээгдэхүүн сайн байх ёстой зүйлд бодитой бус хүчин чармайлт, авьяас чадвар шаарддаг. Энэ нь хөгжүүлэлтийн хэрэгсэл, тоглуулагч байхгүй тохиолдолд HTML5 Canvas нь Flash-ийг огт орлохгүйтэй төстэй юм. Түүгээр ч зогсохгүй Firestore нь өгөгдлийн цэвэр байдал, ариутгасан баталгаажуулалтын хүсэлд автсан бөгөөд энэ нь энгийн бизнесийн хэрэглэгчтэй нийцэхгүй байна. ажиллах дуртай: түүний хувьд бүх зүйл сонголттой байдаг, учир нь эцсээ хүртэл бүх зүйл ноорог юм.
FireBase-ийн гол сул тал нь ихэнх вэб хөгжүүлэгчид хувиршгүй байдлын талаар мэдэхээс өмнө үйлчлүүлэгчийг хэдэн жилийн өмнө бүтээсэн явдал юм. Үүнээс болж FireBase нь таныг өгөгдлийг өөрчлөх болно гэж үздэг тул хэрэглэгчийн өгсөн өөрчлөгдөшгүй байдлын давуу талыг ашиглахгүй. Энэ нь мөн хэрэглэгч рүү илгээсэн агшин зуурын агшин дахь өгөгдлийг дахин ашиглахгүй тул ялгааг улам хүндрүүлдэг. Томоохон баримт бичгийн хувьд түүний өөрчлөгддөг зөрүүд суурилсан гүйлгээний механизм нь ердөө л хангалтгүй юм. Залуус аа, бидэнд аль хэдийн байна WeakMap JavaScript дээр. Энэ нь тухтай.
Хэрэв та өгөгдөлд хүссэн хэлбэрийг өгч, модыг хэт том болгохгүй бол энэ асуудлыг тойрч гарах боломжтой. Гэхдээ хөгжүүлэгчид өгөгдлийн сангийн дизайны талаар нухацтай практик зөвлөгөөг хослуулан, өөрчлөгддөггүй байдлыг ашигласан үнэхээр сайн клиент API-г гаргавал FireBase илүү сонирхолтой байх болов уу гэж би сонирхож байна. Харин эвдрээгүй зүйлийг засах гэж оролдсон бололтой, энэ нь улам дордуулсан.
Би Firestore-ийг бүтээсэн бүх логикийг мэдэхгүй. Хар хайрцагны доторх сэдэл сэдлийн талаар таамаглах нь бас зугаа цэнгэлийн нэг хэсэг юм. Маш төстэй боловч юутай ч зүйрлэшгүй хоёр өгөгдлийн сангийн энэ зэрэгцэх нь маш ховор тохиолддог. Энэ нь хэн нэгэн бодсон шиг: "Firebase бол зүгээр л бидний Google Cloud дээр дуурайж болох функц", гэхдээ бодит ертөнцийн шаардлагыг тодорхойлох эсвэл эдгээр бүх шаардлагыг хангасан ашигтай шийдлүүдийг бий болгох үзэл баримтлалыг хараахан олж чадаагүй байна. "Хөгжүүлэгчид энэ талаар бодож үзээрэй. Зүгээр л UI-г сайхан болго... Та илүү гал нэмж чадах уу?"
Би өгөгдлийн бүтцийн талаар хэд хэдэн зүйлийг ойлгож байна. "Нэг том JSON модны бүх зүйл" гэсэн ойлголтыг би мэдээллийн сангаас том хэмжээний бүтцийн аливаа мэдрэмжийг хийсвэрлэх гэсэн оролдлого гэж би мэдээж харж байна. Програм хангамж нь аливаа эргэлзээтэй өгөгдлийн бүтцийн фракталыг зүгээр л даван туулж чадна гэж хүлээх нь зүгээр л галзуу юм. Би ямар муухай зүйл болохыг төсөөлөх ч хэрэггүй, би кодын нарийн шалгалт хийж, Би та нарын мөрөөдөж байгаагүй зүйлсийг харсан. Гэхдээ би сайн бүтэц ямар байдгийг бас мэднэ. и . Firestore нь логик юм шиг санагдаж, үүнийг бүтээсэн хүмүүс сайн ажилласан гэж боддог ертөнцийг би төсөөлж байна. Гэхдээ бид энэ ертөнцөд амьдардаггүй.
FireBase-ийн асуулгын дэмжлэг нь ямар ч стандартын хувьд муу бөгөөд бараг байхгүй. Энэ нь мэдээжийн хэрэг сайжруулах, ядаж засвар хийх шаардлагатай. Гэхдээ Firestore нь энгийн SQL-д байдаг нэг хэмжээст индексээр хязгаарлагддаг тул илүү сайн биш юм. Хэрэв танд эмх замбараагүй өгөгдөл дээр хүмүүс ажилладаг асуулга хэрэгтэй бол танд бүрэн текст хайлт, олон хүрээний шүүлтүүр, хэрэглэгчийн тодорхойлсон захиалга хэрэгтэй. Нарийвчилсан шалгалтаар энгийн SQL-ийн функцууд дангаараа хэт хязгаарлагдмал байдаг. Нэмж дурдахад хүмүүсийн үйлдвэрлэлд ажиллуулж болох цорын ганц SQL асуулга бол хурдан асуулга юм. Танд ухаалаг мэдээллийн бүтэц бүхий захиалгат индексжүүлэлтийн шийдэл хэрэгтэй болно. Бусад бүх зүйлд дор хаяж газрын зургийг нэмэгдүүлэх эсвэл үүнтэй төстэй зүйл байх ёстой.
Хэрэв та энэ талаарх мэдээллийг Google Docs-оос хайвал BigTable, BigQuery гэх мэт зүйл рүү чиглүүлэх болно гэж найдаж байна. Гэсэн хэдий ч, эдгээр бүх шийдлүүд нь маш нягт корпорацийн борлуулалтын үг хэллэгүүд дагалддаг тул та хурдан эргэж, өөр зүйл хайж эхлэх болно.
Бодит цагийн мэдээллийн сантай бол хамгийн сүүлд хүсч буй зүйл бол удирдлагын цалингийн шатлалтай хүмүүсийн хийсэн зүйл юм.
(*) Энэ бол хошигнол, тийм зүйл байхгүй .
Сурталчилгааны эрх
хайж байна дибаг хийх төслүүд, хөгжүүлэлт, байршуулах сервер үү? Та бол гарцаагүй манай үйлчлүүлэгч 🙂 Төрөл бүрийн тохиргоотой серверүүдийн өдөр тутмын үнэ, DDoS болон Windows-ийн эсрэг лицензүүд үнэд аль хэдийн багтсан болно.
Эх сурвалж: www.habr.com