Чыныгы тиркемелерде ClickHouse колдонуунун теориясы жана практикасы. Александр Зайцев (2018)

Азыр дээрлик бардык жерде көп маалыматтар бар экендигине карабастан, аналитикалык маалымат базалары дагы эле экзотикалык. Алар начар белгилүү жана андан да начар, аларды натыйжалуу колдоно алышат. Көптөр башка сценарийлер үчүн иштелип чыккан MySQL же PostgreSQL менен "кактусту жей беришет", NoSQL менен кыйналышат же коммерциялык чечимдер үчүн ашыкча төлөшөт. ClickHouse оюндун эрежелерин өзгөртөт жана аналитикалык DBMS дүйнөсүнө кирүү босогосун кыйла төмөндөтөт.

BackEnd Conf 2018 баяндамасы жана ал баяндамачынын уруксаты менен жарыяланат.

Мен киммин жана эмне үчүн ClickHouse жөнүндө айтып жатам? Мен ClickHouse колдонгон LifeStreet компаниясынын өнүктүрүү боюнча директорумун. Ошондой эле, мен Altinity компаниясынын негиздөөчүсү болом. Бул ClickHouse'ду илгерилетүүчү жана Яндекстин ClickHouse'ду ийгиликтүү болушуна жардам берген Яндекс өнөктөшү. Ошондой эле ClickHouse жөнүндө билим менен бөлүшүүгө даяр.

А мен Петя Зайцевдин бир тууганы эмесмин. Менден бул тууралуу көп сурашат. Жок, биз бир тууган эмеспиз.

ClickHouse "баары билет":

• Абдан тез,
• Абдан ыңгайлуу
• Яндексте колдонулат.

Кайсы компанияларда жана кандайча колдонулганы азыраак белгилүү.

Мен эмне үчүн, кайда жана кантип ClickHouse колдонуларын айтып берем, Яндекстен башка.

Мен сизге конкреттүү тапшырмалар ClickHouse жардамы менен ар кандай компанияларда кандайча чечилерин, кандай ClickHouse куралдарын өз милдеттериңиз үчүн колдоно аласыз жана алар ар кандай компанияларда кандай колдонулганын айтып берем.

Мен ClickHouseду ар кандай бурчтан көрсөткөн үч мисалды алдым. Кызыктуу болот деп ойлойм.

Биринчи суроо: "Эмне үчүн бизге ClickHouse керек?". Бул абдан ачык суроо окшойт, бирок ага бир эмес, бир нече жооп бар.

• Биринчи жооп аткаруу үчүн. ClickHouse абдан тез. ClickHouseдагы аналитика да абдан тез. Ал көп учурда башка нерсе өтө жай же өтө начар болгон жерде колдонулушу мүмкүн.
• Экинчи жооп - бул чыгымдар. Ал эми биринчи кезекте, масштабдуу наркы. Мисалы, Vertica - бул абдан сонун маалымат базасы. Эгер сизде терабайт көп маалымат жок болсо, ал абдан жакшы иштейт. Ал эми жүздөгөн терабайттарга же петабайттарга келгенде, лицензиянын жана колдоонун баасы кыйла олуттуу сумманы түзөт. Жана бул кымбат. Жана ClickHouse акысыз.
• Үчүнчү жооп - операциялык чыгымдар. Бул бир аз башкача мамиле. RedShift сонун аналогу болуп саналат. RedShiftте сиз тез чечим кабыл ала аласыз. Бул жакшы иштейт, бирок ошол эле учурда, ар бир саат, күн сайын жана ай сайын, сиз Amazonга абдан кымбат төлөйсүз, анткени бул абдан кымбат кызмат. Google BigQuery да. Эгер кимдир бирөө аны колдонгон болсо, анда ал жерде сиз бир нече суроо-талаптарды иштетип, күтүлбөгөн жерден жүздөгөн долларга эсеп ала аларыңызды билет.

ClickHouseда мындай көйгөйлөр жок.

ClickHouse азыр кайда колдонулат? Яндекс тышкары, ClickHouse ар кандай ишканалардын жана компаниялардын бир тутам колдонулат.

• Биринчиден, бул веб-тиркемелердин аналитикасы, башкача айтканда, бул Яндекстен келген колдонуу учуру.
• Көптөгөн AdTech компаниялар ClickHouse колдонушат.
• Ар кандай булактардан алынган транзакция журналдарын талдоо керек болгон көптөгөн компаниялар.
• Бир нече компаниялар коопсуздук журналдарын көзөмөлдөө үчүн ClickHouse колдонушат. Аларды ClickHouseга жүктөп, отчетторду түзүп, керектүү натыйжаларды алышат.
• Компаниялар аны каржылык талдоодо колдоно башташат, б.а. бара-бара чоң бизнес да ClickHouseга жакындашууда.
• булуттун жарыгы. Эгер кимдир бирөө ClickHouse ээрчисе, анда алар бул компаниянын атын уккандыр. Бул коомчулуктун эң маанилүү салымдарынын бири. Жана алар абдан олуттуу ClickHouse орнотууга ээ. Мисалы, алар ClickHouse үчүн Kafka Engine жасашкан.
• Байланыш ишканалары колдоно баштады. Бир нече компаниялар ClickHouseду концепциянын далили катары же өндүрүштө колдонушат.
• Бир компания өндүрүш процесстерин көзөмөлдөө үчүн ClickHouse колдонот. Алар микросхемаларды сынап көрүшөт, бир топ параметрлерди жазат, 2ге жакын мүнөздөмөлөр бар. Анан оюндун жакшы же жаман экенин талдап чыгышат.
• Блокчейн аналитикасы. Bloxy.info деген орусиялык компания бар. Бул ethereum тармагын талдоо болуп саналат. Алар муну ClickHouseда да жасашты.

Жана өлчөмү маанилүү эмес. Бир кичинекей серверди колдонгон көптөгөн компаниялар бар. Жана алардын көйгөйлөрүн чечүүгө мүмкүнчүлүк берет. Жана андан да көп компаниялар көптөгөн серверлердин чоң кластерлерин же ондогон серверлерди колдонушат.

Ал эми жазууларды карасаңыз, анда:

• Яндекс: 500+ серверлер, ал жерде күнүнө 25 миллиард жазуу сакталат.
• LifeStreet: 60 сервер, күнүнө болжол менен 75 миллиард жазуу. Яндекске караганда серверлер аз, жазуулар көп.
• CloudFlare: 36 сервер, алар күнүнө 200 миллиард жазууну сактап калышат. Алардын серверлери дагы азыраак жана андан да көп маалымат сакталат.
• Bloomberg: 102 сервер, күнүнө болжол менен триллион жазуу. Рекорд ээси.

Географиялык жактан бул да көп. Бул карта бул жерде ClickHouse дүйнөдө колдонулуп жаткан жылуулук картасын көрсөтөт. Бул жерде Россия, Кытай, Америка айкын көрүнүп турат. Европа өлкөлөрү аз. Жана 4 кластер бар.

Бул салыштырмалуу анализ, абсолюттук цифраларды издөөнүн кереги жок. Бул Altinity веб-сайтында англис тилиндеги материалдарды окуган коноктордун анализи, анткени ал жерде орус тилдүүлөр жок. Ал эми Орусия, Украина, Белоруссия, башкача айтканда, коомчулуктун орус тилдүү бөлүгү, булар эң көп колдонуучулар. Андан кийин АКШ жана Канада келет. Кытай абдан кууп баратат. Алты ай мурун ал жакта Кытай дээрлик жок болчу, азыр Кытай Европаны басып өтүп, өсүүнү улантууда. Эски Европа да артта калган эмес жана ClickHouse колдонуу боюнча лидер, таң калыштуусу, Франция.

Мунун баарын эмнеге айтып жатам? ClickHouse чоң маалыматтарды талдоо үчүн стандарттуу чечим болуп жатканын көрсөтүү үчүн жана буга чейин көп жерлерде колдонулат. Эгер сиз аны колдонсоңуз, сиз туура тенденциядасыз. Эгер сиз аны али колдонбосоңуз, анда сиз жалгыз калып калам деп коркпоңуз жана сизге эч ким жардам бербейт, анткени көптөр муну менен алектенип жатышат.

Булар бир нече компанияларда чыныгы ClickHouse колдонуунун мисалдары.

• Биринчи мисал - бул жарнама тармагы: Verticaдан ClickHouseга көчүү. Мен Verticaдан өткөн же өтүү процессинде турган бир нече компанияларды билем.
• Экинчи мисал - ClickHouseдагы транзакциялык сактагыч. Бул антипаттерндерге негизделген мисал. Иштеп чыгуучулардын кеңеши боюнча ClickHouseда кылбоо керек болгон нерселердин баары ушул жерде жасалат. Жана ал ушунчалык натыйжалуу жасалгандыктан, ал иштейт. Жана бул типтүү транзакциялык чечимге караганда алда канча жакшы иштейт.
• Үчүнчү мисал ClickHouse боюнча бөлүштүрүлгөн эсептөө болуп саналат. ClickHouseду Hadoop экосистемасына кантип интеграциялоого болот деген суроо пайда болду. Мен компаниянын ClickHouseдагы картаны азайтуу контейнерине окшош нерсени кантип жасаганынын мисалын көрсөтөм, маалыматтарды локализациялоого көз салуу ж.б., абдан маанилүү эмес тапшырманы эсептөө.

• LifeStreet - бул жарнама тармагы менен келген бардык технологияларга ээ Ad Tech компаниясы.
• Ал жарнамаларды оптималдаштыруу, программалык соодалоо менен алектенет.
• Көптөгөн маалыматтар: күнүнө болжол менен 10 миллиард окуя. Ошол эле учурда ал жердеги окуяларды бир нече кичи окуяларга бөлүүгө болот.
• Бул маалыматтардын көптөгөн кардарлары бар, булар бир гана адамдар эмес, андан да көп - булар программалык соодалашуу менен алектенген ар кандай алгоритмдер.

Компания узак жана татаал жолду басып өттү. Мен бул тууралуу HighLoad боюнча сүйлөштүм. Биринчиден, LifeStreet MySQLден (Oracleда кыскача токтоп) Verticaга көчтү. Жана сиз бул тууралуу окуяны таба аласыз.

Жана баары абдан жакшы болду, бирок тез эле маалыматтар өсүп жатат жана Vertica кымбат экени айкын болду. Ошондуктан ар кандай альтернативалар изделди. Алардын айрымдары бул жерде келтирилген. Чындыгында, биз 13-жылдан 16-жылга чейин рынокто жеткиликтүү болгон жана функционалдык жагынан болжолдуу түрдө ылайыктуу болгон дээрлик бардык маалымат базаларынын концепциясын же кээде натыйжалуулугун сынап көрдүк. Ошондой эле мен алардын айрымдары жөнүндө HighLoad боюнча сүйлөштүм.

Берилиштер өскөндүктөн, биринчи кезекте Verticaдан көчүү милдети болгон. Жана алар жыл өткөн сайын өскөн. Анан алар текчеге чыгышты, бирок ошентсе да. Жана бул өсүштү болжолдоо, кандайдыр бир аналитика жасалышы керек болгон маалыматтардын көлөмүнө карата бизнес талаптары, петабайттар жакын арада талкууланаары айкын болду. Жана петабайттарды төлөө буга чейин абдан кымбат, ошондуктан биз кайда баруунун альтернативасын издеп жатканбыз.

Кайда баруу керек? Анан көпкө чейин кайда баруу такыр түшүнүксүз болчу, анткени бир жагынан коммерциялык маалымат базалары бар, алар жакшы иштейт окшойт. Кээ бирлери Vertica сыяктуу дээрлик жакшы иштейт, айрымдары андан да начар. Бирок алардын баары кымбат, андан арзан жана жакшыраак эч нерсе табылган жок.

Башка жагынан алганда, ачык булактуу чечимдер бар, алар анча көп эмес, б.а. аналитика үчүн, аларды манжа менен санаса болот. Жана алар бекер же арзан, бирок жай. Жана алар көбүнчө керектүү жана пайдалуу функционалдуулукка ээ болушпайт.

Ал эми коммерциялык маалымат базаларындагы жакшылыктарды жана ачык булактагы акысыз нерселерди бириктире турган эч нерсе жок болчу.

Күтүлбөгөн жерден Яндекс ClickHouse'ду шляпадан сыйкырчыдай, коёндой чыгарып салганга чейин эч нерсе болгон жок. Бул күтүүсүз чечим болду, алар дагы эле суроону беришет: "Эмне үчүн?", Бирок ошентсе да.

Ошол замат 2016-жылдын жайында, биз ClickHouse деген эмне экенин карай баштадык. Ал эми кээде Vertica караганда тезирээк болот экен. Биз ар кандай суроолор боюнча ар кандай сценарийлерди сынап көрдүк. Эгерде суроо бир гана таблицаны колдонсо, башкача айтканда, эч кандай кошулмаларсыз (кошуу), анда ClickHouse Verticaга караганда эки эсе ылдам болгон.

Мен өтө жалкоо болгон жокмун жана башка күнү Яндекс тесттерин карадым. Бул жерде да ушундай: ClickHouse Verticaдан эки эсе ылдам, ошондуктан алар бул жөнүндө көп айтышат.

Бирок, эгерде сурамдарда кошулуулар бар болсо, анда баары так эмес болуп чыгат. Ал эми ClickHouse Verticaдан эки эсе жайыраак иштеши мүмкүн. Эгер өтүнүчтү бир аз оңдоп, кайра жазсаңыз, анда алар болжол менен бирдей. Жаман эмес. Жана бекер.

Жана тесттин жыйынтыгын алып, аны ар кандай бурчтан карап, LifeStreet ClickHouse сайтына жөнөдү.

Бул 16-жыл, эсиңизге салам. Бул чычкандардын тамашага окшоп ыйлап, өздөрүн сайган, бирок кактусту жей берген. Жана бул майда-чүйдөсүнө чейин сүрөттөлгөн, бул тууралуу видео бар, ж.б.

Ошондуктан, мен бул тууралуу кенен сөз кылбайм, натыйжалары жана анда айтпаган бир нече кызыктуу нерселер жөнүндө гана айтам.

натыйжалары болуп саналат:

• Ийгиликтүү миграция жана бир жылдан ашык система өндүрүштө иштеп жатат.
• Эмгек ендурумдуулугу жана ийкемдуулугу жогорулады. Биз күнүнө, анан кыска убакытка сактай ала турган 10 миллиард жазуунун ичинен LifeStreet азыр күнүнө 75 миллиард жазууну сактайт жана муну 3 ай же андан көп убакытка аткара алат. Эгерде сиз эң чокусунда эсептесеңиз, анда бул секундасына бир миллион окуяга чейин жетет. Бул системага күнүнө миллиондон ашык SQL сурамдары, негизинен ар кандай роботтордон келет.
• Verticaга караганда ClickHouse үчүн көбүрөөк серверлер колдонулганына карабастан, алар аппараттык камсыздоодо да үнөмдөлгөн, анткени Verticaда кыйла кымбат SAS дисктери колдонулган. ClickHouse SATA колдонгон. Эмне үчүн? Анткени Vertica кыстаруу синхрондуу. Ал эми синхрондоштуруу дисктер өтө эле жайлатпасын, ошондой эле тармак өтө эле жайлабасын, башкача айтканда, бир топ кымбат операцияны талап кылат. Ал эми ClickHouse кыстармасында асинхрондуу. Андан тышкары, сиз ар дайым бардыгын жергиликтүү түрдө жаза аласыз, бул үчүн эч кандай кошумча чыгымдар жок, андыктан маалымат Vertikaга караганда ClickHouseга тезирээк, жада калса жайыраак дисктерде да киргизилиши мүмкүн. Ал эми окуу болжол менен бирдей. SATA боюнча окуу, эгерде алар RAIDде болсо, анда мунун баары жетиштүү ылдам.
• Лицензия менен чектелбейт, б.а. 3 сервердеги 60 петабайт маалымат (20 сервер бир реплика) жана фактылар жана агрегаттардагы 6 триллион жазуу. Мындай эч нерсе Vertica мүмкүн эмес.

Мен азыр бул мисалда практикалык нерселерге кайрылам.

• Биринчиси - натыйжалуу схема. Көп нерсе схемадан көз каранды.
• Экинчиси - натыйжалуу SQL генерациясы.

Кадимки OLAP суроосу тандоо болуп саналат. Кээ бир мамычалар топко өтсө, кээ бир мамычалар агрегаттык функцияларга барат. Кайда бар, аны кубдун бир кесими катары көрсөтсө болот. Бүткүл топту проекция катары кароого болот. Мына ушундан улам ал көп варианттуу маалыматтарды талдоо деп аталат.

Жана көп учурда бул жылдыз схемасы түрүндө моделдештирилет, бул чындыктын борбордук факты жана мүнөздөмөлөрү болгондо, капталдарда, нурлардын боюнда.

Ал эми физикалык дизайн боюнча, ал үстөлгө кантип туура келет, алар адатта нормалдаштырылган өкүлчүлүктү жасашат. Сиз нормадан чыгара аласыз, бирок ал дискте кымбат жана сурамдарда анча эффективдүү эмес. Ошондуктан, алар, адатта, нормалдаштырылган өкүлчүлүктү, башкача айтканда, факты таблицасын жана көптөгөн, көптөгөн өлчөмдүү таблицаларды түзөт.

Бирок ClickHouseда жакшы иштебейт. Эки себеп бар:

• Биринчиси, ClickHouseда анча жакшы кошулуулар жок, б.а. кошулуулар бар, бирок алар начар. Жаман болгондо.
• Экинчиси, таблицалардын жаңыланбаганы. Адатта, жылдыз схемасынын айланасында жайгашкан бул плиталарда бир нерсени өзгөртүү керек. Мисалы, кардардын аты, фирманын аты ж.б. Ал иштебейт.

Мындан чыгуунун жолу ClickHouseда бар. ал тургай эки:

• Биринчиси - сөздүктөрдү колдонуу. Тышкы сөздүктөр 99% жылдыз схемасы, жаңыртуулар жана башкалар менен көйгөйдү чечүүгө жардам берет.
• Экинчиси - массивдерди колдонуу. Массивдер ошондой эле кошулмалардан жана нормалдаштыруу көйгөйлөрүнөн арылууга жардам берет.

• Кошулуу талап кылынбайт.
• Жаңылануучу. 2018-жылдын март айынан баштап сөздүктөрдү жарым-жартылай жаңыртуу, башкача айтканда, өзгөргөн жазууларды жаңыртуу үчүн документсиз мүмкүнчүлүк пайда болду (муну документациядан таба албайсыз). Иш жүзүндө бул үстөл сыяктуу.
• Ар дайым эс тутумда болгондуктан, сөздүк менен кошулуу дискте турган таблицага караганда тезирээк иштейт жана ал кэште экендиги азырынча чындык эмес, балким, жок.

• Сизге кошулуунун да кереги жок.
• Бул 1ден көпкө чейин компакттуу өкүлчүлүк.
• Жана менин оюмча, массивдер геэктер үчүн жасалган. Бул лямбда функциялары жана башкалар.

Бул кызыл сөздөр үчүн эмес. Бул абдан жөнөкөй жана жарашыктуу түрдө көп нерселерди жасоого мүмкүндүк берген абдан күчтүү функция.

Массивдерди чечүүгө жардам берген типтүү мисалдар. Бул мисалдар жетиштүү жөнөкөй жана түшүнүктүү:

• Тегдер боюнча издөө. Эгер сизде хэштегтер бар болсо жана хэштег боюнча кээ бир билдирүүлөрдү тапкыңыз келсе.
• Ачкыч-маани жуптары боюнча издөө. Маанилүү кээ бир атрибуттар да бар.
• Башка нерсеге которуу керек болгон баскычтардын тизмелерин сактоо.

Бул милдеттердин бардыгын массивдерсиз эле чечсе болот. Тегдер кандайдыр бир сапка коюлуп, кадимки туюнтма менен же өзүнчө таблицада тандалышы мүмкүн, бирок андан кийин сиз кошулууларды жасашыңыз керек.

Ал эми ClickHouseда эч нерсе кылуунун кереги жок, хэштегтер үчүн сап массивдерин сүрөттөп же ачкыч-маанилүү системалар үчүн уя структурасын жасоо жетиштүү.

Уюшкан структура эң жакшы ат болбошу мүмкүн. Бул аталышта жалпы бөлүккө ээ болгон эки массив жана айрым тиешелүү мүнөздөмөлөр.

Жана теги боюнча издөө абдан оңой. Функциясы бар has, ал массивде элемент бар экендигин текшерет. Ар бир адам, биздин конференцияга тиешелүү бардык жазууларды тапты.

Subid боюнча издөө бир аз татаалыраак. Биз адегенде ачкычтын индексин табышыбыз керек, андан кийин бул индекс менен элементти алып, бул маани бизге керек экенин текшеришибиз керек. Бирок, бул абдан жөнөкөй жана компакттуу.

Эгер баарын бир сапта сактасаңыз, жазгыңыз келген туруктуу сөз айкашы, биринчиден, олдоксон болмок. Экинчиден, ал эки массивге караганда алда канча узагыраак иштеген.

Башка мисал. Сизде ID сакталган массив бар. Жана аларды аттарга которо аласыз. Функция arrayMap. Бул типтүү ламбда функциясы. Сиз лямбда туюнтмаларын ошол жерге өткөрүп бересиз. Ал сөздүктөн ар бир идентификатордун аталышынын маанисин чыгарып алат.

Издөө да ушундай жол менен жүргүзүлүшү мүмкүн. Элементтер эмнеге дал келгенин текшерген предикат функциясы өткөрүлөт.

Бул нерселер схеманы абдан жөнөкөйлөтүп, бир топ маселелерди чечет.

Бирок биз туш болгон кийинки көйгөй жана мен айтып кетким келет, бул эффективдүү суроо.

• ClickHouseда суроо пландоочу жок. Такыр жок.
• Ошентсе да, татаал суроолор дагы эле пландаштырылышы керек. Кандай учурларда?
• Суроодо бир нече кошулмалар бар болсо, сиз аларды кошумча тандоолорго ороп аласыз. Жана алардын аткарылышынын тартиби маанилүү.
• Ал эми экинчиси - суроо-талап таратылса. Анткени бөлүштүрүлгөн суроодо эң ички тандоо гана бөлүштүрүлөт, ал эми калганынын баары сиз туташкан жана ал жерде аткарылган бир серверге өткөрүлүп берилет. Ошондуктан, эгерде сиз көп кошулуу (кошулуу) менен бөлүштүрүлгөн суроо-талаптар болсо, анда сиз тартипти тандооңуз керек.

Жөнөкөй учурларда да, кээде пландоочунун ишин аткарып, суроо-талаптарды бир аз кайра жазуу керек.

Бул жерде бир мисал. Сол жагында алдыңкы 5 өлкөнү көрсөткөн суроо бар. Ал эми менин оюмча, 2,5 секунд талап кылынат. Ал эми оң жагында, ошол эле суроо, бирок бир аз кайра жазылган. Сап боюнча топтоонун ордуна, биз ачкыч (int) боюнча топтой баштадык. Жана ал тезирээк. Анан жыйынтыкка сөздүк туташтырдык. 2,5 секунддун ордуна суроо 1,5 секундду талап кылат. Бул Жакшы.

Чыпкаларды кайра жазуу менен окшош мисал. Бул жерде Россияга кайрылуу. Ал 5 секунд иштейт. Эгерде биз аны кайра сапты эмес, Россияга тиешелүү баскычтардын кээ бир топтому менен сандарды салыштыра тургандай кылып кайра жазсак, анда ал тезирээк болот.

Мындай трюктар көп. Жана алар сизге тез иштеп жатат деп ойлогон сурамдарды кыйла тездетүүгө мүмкүндүк берет, же тескерисинче, жай иштеп жатат. Аларды дагы тезирээк жасоого болот.

• Бөлүштүрүлгөн режимде максималдуу иштөө.
• Минималдуу түрлөр боюнча сорттоо, мен ints боюнча кылгандай.
• Эгерде кандайдыр бир кошулуулар (кошулуулар), сөздүктөр бар болсо, анда аларды акыркы чара катары жасаганыңыз жакшы, эгер сизде маалымат жок дегенде жарым-жартылай топтоштурулган болсо, анда кошулуу операциясы же сөздүк чакыруусу азыраак чакырылат жана ал тезирээк болот. .
• Чыпкаларды алмаштыруу.

Башка ыкмалар бар, мен көрсөткөндөр эле эмес. Алардын баары кээде суроо-талаптардын аткарылышын бир кыйла тездетет.

Келгиле, кийинки мисалга өтөбүз. АКШдан X компаниясы. Ал эмне кылып жатат?

Тапшырма бар эле:

• Жарнамалык транзакцияларды оффлайн байланыштыруу.
• Ар кандай байланыш моделдерин моделдөө.

Сценарий кандай?

Жөнөкөй конок сайтка келет, мисалы айына 20 жолу ар кандай жарнамалардан же ушуга окшогон кээде эч кандай жарнамасыз келет, анткени ал бул сайтты эстейт. Кээ бир буюмдарды карайт, аларды себетке салат, себеттен чыгарат. Анан, акыры, бир нерсе сатып алат.

Орундуу суроолор: "Керек болсо жарнак үчүн ким төлөшү керек?" жана "Эгер бар болсо, ага кандай жарнама таасир эткен?". Башкача айтканда, ал эмне үчүн сатып алды жана бул кишиге окшогондорду кантип сатып алды?

Бул көйгөйдү чечүү үчүн сиз веб-сайтта болуп жаткан окуяларды туура жол менен байланыштырышыңыз керек, башкача айтканда, кандайдыр бир жол менен алардын ортосунда байланыш түзүү керек. Андан кийин алар DWH анализге жөнөтүлөт. Жана ушул анализдин негизинде ким жана кандай жарнамаларды көрсөтүү үчүн моделдерди түзүңүз.

Жарнама транзакциясы - бул жарнаманы көрсөтүүдөн баштап, андан кийин кандайдыр бир нерсе болуп, андан кийин сатып алуу, анан сатып алууда сатып алуулар болушу мүмкүн болгон тиешелүү колдонуучу окуяларынын жыйындысы. Мисалы, бул мобилдик тиркеме же мобилдик оюн болсо, анда, адатта, тиркемени орнотуу акысыз ишке ашат жана ал жерде бир нерсе жасалса, анда бул үчүн акча талап кылынышы мүмкүн. Ал эми адам тиркемеде канчалык көп коротсо, ошончолук баалуу болот. Бирок бул үчүн баарын туташтыруу керек.

Көптөгөн байланыш моделдери бар.

Эң популярдуу болуп төмөнкүлөр саналат:

• Акыркы өз ара аракеттенүү, мында өз ара аракеттенүү чыкылдатуу же таасирленүү.
• Биринчи өз ара аракеттенүү, б.а. адамды сайтка алып келген биринчи нерсе.
• Сызыктуу айкалышы - баары бирдей.
• Өнүктүрүү.
• Жана башка.

Анан кантип баары биринчи кезекте иштеген? Runtime жана Cassandra бар болчу. Кассандра транзакцияларды сактоочу катары колдонулган, башкача айтканда, бардык тиешелүү транзакциялар анда сакталган. Жана Runtime'да кандайдыр бир окуя келгенде, мисалы, кандайдыр бир баракты же башка нерсени көрсөтүү, анда Кассандрага өтүнүч берилди - андай адам барбы же жокпу. Андан кийин ага тиешелүү бүтүмдөр алынган. Жана байланыш түзүлдү.

Ал эми суранычта транзакция идентификатору бар экени бактылуу болсо, анда бул оңой. Бирок, адатта, ийгилик жок. Ошондуктан, акыркы транзакцияны же акыркы чыкылдатуу менен бүтүмдү табуу керек болчу, ж.б.

Жана мунун баары абдан жакшы иштеди, эгерде байлоо акыркы чыкылдатууга чейин болду. Анткени бир айга терезе коюп алсак, айына 10 миллион, айына 300 миллион чыкылдатуу бар. Кассандрада тез иштеши үчүн бардыгы эс тутумда болушу керек, анткени Runtime тез жооп бериши керек, ал болжол менен 10-15 серверди талап кылды.

Жана алар транзакцияны дисплейге байланыштыргылары келгенде, бул дароо анчалык деле кызыктуу эмес болуп чыкты. Эмне үчүн? Бул 30 эсе көп окуяларды сактоо керек экенин көрүүгө болот. Жана, ошого жараша, сизге 30 эсе көп серверлер керек. Ал эми бул кандайдыр бир астрономиялык фигура экени белгилүү болду. Runtime'да серверлер кыйла аз болгонуна карабастан, байланыштыруу үчүн 500 серверге чейин кармап туруу, анда бул кандайдыр бир туура эмес көрсөткүч. Анан эмне кыларын ойлоно башташты.

Биз ClickHouseга бардык. Аны ClickHouseда кантип кылса болот? Бир караганда, бул анти-үлгүлөрдүн жыйындысы окшойт.

• Транзакция өсүп жатат, биз ага барган сайын көбүрөөк окуяларды бириктиребиз, башкача айтканда, ал өзгөрүлмө жана ClickHouse өзгөрүлүүчү объекттер менен жакшы иштебейт.
• Бизге конок келгенде, биз анын транзакцияларын ачкыч менен, анын иш сапарынын идентификатору менен чыгарып алышыбыз керек. Бул дагы бир чекит суроосу, алар ClickHouseда муну жасашпайт. Көбүнчө ClickHouse чоң …скандоолорго ээ, бирок бул жерде биз кээ бир жазууларды алышыбыз керек. Ошондой эле антипаттерн.
• Мындан тышкары, транзакция json тилинде болгон, бирок алар аны кайра жазгылары келген жок, ошондуктан алар jsonду структураланбаган түрдө сактап, зарыл болсо, андан бир нерсени чыгарып салгылары келген. Жана бул да антипаттерн.

Башкача айтканда, антипаттерндердин жыйындысы.

Бирок, ошентсе да, ал абдан жакшы иштеген система үчүн чыкты.

Эмне кылынды? ClickHouse пайда болду, ага журналдар ыргытылып, жазууларга бөлүнгөн. ClickHouseдан журналдарды алган атрибуттуу кызмат пайда болду. Андан кийин, ар бир киргизүү үчүн, зыярат идентификатору боюнча, мен али иштетиле элек транзакцияларды жана плюс снапшоттарды, б.а. буга чейин туташкан транзакцияларды, тагыраак айтканда, мурунку иштин жыйынтыгын алдым. Мен алардан логика жасап, туура транзакцияны тандап, жаңы окуяларды туташтырдым. Кайра катталды. Журнал ClickHouseга кайтып келди, башкача айтканда, бул дайыма циклдик система. Андан тышкары, мен аны анализдөө үчүн DWHге бардым.

Дал ушул формада ал абдан жакшы иштебей калган. Ал эми ClickHouse үчүн жеңилдетүү үчүн, зыярат идентификатору боюнча суроо-талап болгондо, алар бул сурамдарды 1-000 визит идентификаторлорунун блокторуна топтоштуруп, 2-000 адам үчүн бардык транзакцияларды алып салышты. Анан баары иштеди.

Эгерде сиз ClickHouse ичин карасаңыз, анда мунун бардыгын тейлеген 3 гана негизги таблица бар.

Журналдар жүктөлгөн биринчи таблица жана журналдар дээрлик иштетилбестен жүктөлөт.

Экинчи стол. Материалдаштырылган көз караш аркылуу алиге таандык кылынбаган окуялар, б.а., байланышы жок окуялар бул журналдардан тиштеп алынган. Жана материалдашкан көрүнүш аркылуу транзакциялар сүрөттү түзүү үчүн бул журналдардан чыгарылды. Башкача айтканда, атайын материалдаштырылган көрүнүш, транзакциянын акыркы топтолгон абалын, тактап айтканда, сүрөттү курган.

Бул жерде SQLде жазылган текст. Мен андагы бир нече маанилүү нерселерге токтолгум келет.

Биринчи маанилүү нерсе - ClickHouseдагы json'дон мамычаларды жана талааларды чыгаруу мүмкүнчүлүгү. Башкача айтканда, ClickHouse json менен иштөө үчүн кээ бир ыкмалары бар. Алар абдан примитивдүү.

visitParamExtractInt сизге json атрибуттарын чыгарууга мүмкүндүк берет, башкача айтканда, биринчи хит иштейт. Жана ушундай жол менен сиз транзакция идентификаторун чыгара аласыз же ID'ге кирсеңиз болот. Бул убакыт.

Экинчиден, бул жерде татаал материалдашкан талаа колдонулат. Бул эмнени билдирет? Бул сиз аны таблицага киргизе албайсыз, башкача айтканда, ал салынбайт, ал эсептелип, киргизилгенде сакталат. чаптап жатканда, ClickHouse сиз үчүн иштейт. Кийинчерээк сизге керектүү нерсе json'дон чыгарылып салынган.

Бул учурда, материалдык көрүнүш чийки катарлар үчүн. Ал эми иш жүзүндө чийки журналдары менен биринчи стол жөн гана колдонулат. Анан эмне кылат? Биринчиден, ал сорттоону өзгөртөт, б.а. сорттоо азыр зыярат идентификатору боюнча жүрөт, анткени биз анын транзакциясын конкреттүү адам үчүн тезинен чыгарып алышыбыз керек.

Экинчи маанилүү нерсе - index_granularity. Эгер сиз MergeTreeди көргөн болсоңуз, ал демейки index_granularity боюнча адатта 8 болот. Бул эмне? Бул индекстин сейректигинин параметри. ClickHouse-да индекс сейрек, ал эч качан ар бир жазууну индекстебейт. Ал муну ар бир 192 жолу жасайт. Жана бул көп маалыматтарды эсептөө керек болгондо жакшы, бирок аз болгондо жаман, анткени чоң чыгым бар. Ал эми индекстин гранулдуулугун азайтсак, анда биз кошумча чыгымдарды азайтабыз. Аны бирге кыскартуу мүмкүн эмес, анткени эстутум жетишсиз болушу мүмкүн. Индекс ар дайым эс тутумда сакталат.

Snapshot дагы башка кызыктуу ClickHouse функцияларын колдонот.

Биринчиден, бул AggregatingMergeTree. Жана AggregatingMergeTree argMax сактайт, башкача айтканда, бул акыркы убакыт белгисине туура келген транзакциянын абалы. Транзакциялар ар дайым берилген конок үчүн түзүлөт. Бул транзакциянын эң акыркы абалында биз окуяны коштук жана бизде жаңы абал бар. Бул ClickHouseга дагы бир жолу тийди. Жана бул материалдык көрүнүштөгү argMax аркылуу биз ар дайым учурдагы абалды ала алабыз.

• Байланыш Runtime'дан "ажыратылган".
• Айына 3 миллиардга чейин транзакциялар сакталат жана иштетилет. Бул Кассандрадагы, башкача айтканда, типтүү транзакция системасындагыдан да чоң тартип.
• 2x5 ClickHouse серверлеринин кластери. 5 сервер жана ар бир сервердин репликасы бар. Бул чыкылдатууга негизделген атрибуцияны жасоо үчүн Кассандрадагыдан да азыраак жана бул жерде биз таасирге негизделген. Башкача айтканда, серверлердин санын 30 эсеге көбөйтүүнүн ордуна, кыскартууга жетишти.

Ал эми акыркы мисал, акциялардын баасынын өзгөрүшүнүн корреляциясын талдаган каржылык компания Y.

Жана милдет:

• Болжол менен 5 акция бар.
• Ар бир 100 миллисекундда цитаталар белгилүү.
• Маалыматтар 10 жылдан бери топтолгон. Кыязы, кээ бир компаниялар үчүн көбүрөөк, кээ бирлери үчүн аз.
• Жалпысынан болжол менен 100 миллиард сап бар.

Ал эми өзгөрүүлөрдүн корреляциясын эсептөө керек болчу.

Бул жерде эки акция жана алардын котировкалары. Бири көтөрүлүп, экинчиси көтөрүлсө, анда бул оң корреляция, б.а. бири көтөрүлүп, экинчиси көтөрүлөт. Эгерде бири графиктин аягындагыдай өйдө көтөрүлсө, экинчиси төмөндөсө, анда бул терс корреляция, б.а. бири көтөрүлгөндө, экинчиси төмөндөйт.

Бул өз ара өзгөрүүлөрдү талдоо, каржы рыногунда алдын ала айтууга болот.

Бирок милдет оор. Бул үчүн кандай иштер аткарылууда? Бизде 100 миллиард жазуу бар: убакыт, акция жана баа. Биз биринчи 100 миллиард эсе баанын алгоритминен айырманы эсептеп чыгышыбыз керек. RunningDifference - бул ClickHouseдагы функция, ал эки саптын ортосундагы айырманы ырааттуу түрдө эсептейт.

Ошондон кийин, корреляцияны эсептөө керек, ал эми корреляцияны ар бир жуп үчүн эсептөө керек. 5 акция үчүн жуптар 000 млн. Ал эми бул көп, башкача айтканда, 12,5 эсе дал ушундай корреляция функциясын эсептөө керек.

Ал эми кимдир бирөө унутуп калса, анда ͞x жана ͞y мат болуп саналат. үлгү алуу күтүү. Башкача айтканда, тамырларды жана суммаларды гана эсептебестен, бул суммалардын ичинде дагы бир сумманы эсептөө керек. Бир топ эсептөөлөрдү 12,5 миллион жолу жасоо керек, ал тургай сааттар боюнча топтоштурулган. Бизде да көп сааттар бар. Ал эми муну 60 секундда жасашыңыз керек. Бул тамаша.

Жок дегенде кандайдыр бир убакыт болушу керек болчу, анткени мунун баары ClickHouse келгенге чейин абдан, өтө жай иштеген.

Алар аны Hadoop, Spark, Greenplum боюнча эсептөөгө аракет кылышкан. Мунун баары өтө жай же кымбат болгон. Башкача айтканда, кандайдыр бир жол менен эсептесе болот, бирок кийин кымбатка турду.

Анан ClickHouse келип, баары жакшырды.

Корреляцияны локалдаштыруу мүмкүн болбогондуктан, бизде маалыматтардын локализациясында көйгөй бар экенин эскертем. Биз маалыматтардын бир бөлүгүн бир серверге, кээ бирлерин башкасына салып, эсептей албайбыз, бизде бардык маалыматтар бардык жерде болушу керек.

Алар эмне кылышты? Алгач маалыматтар локализацияланат. Ар бир сервер акциялардын белгилүү бир топтомунун баасы боюнча маалыматтарды сактайт. Жана алар бири-бирине дал келбейт. Демек, logReturn'ду параллелдүү жана өз алдынча эсептөөгө болот, мунун баары параллелдүү жана бөлүштүрүлгөн.

Андан кийин биз экспрессивдүүлүгүн жоготпостон, бул маалыматтарды кыскартууну чечтик. Массивдерди колдонууну азайтыңыз, б.а. ар бир мезгил үчүн, акциялардын массивдерин жана баалардын массивдерин түзүңүз. Ошондуктан, ал бир топ аз маалымат мейкиндигин ээлейт. Жана алар менен иштөө бир аз жеңилирээк. Бул дээрлик параллелдүү операциялар, б.а. биз жарым-жартылай параллелдүү окуп, анан серверге жазабыз.

Андан кийин, аны кайталап койсо болот. "R" тамгасы бул маалыматтарды биз кайталаганыбызды билдирет. Башкача айтканда, бизде үч серверде бирдей маалыматтар бар - бул массивдер.

Анан эсептөө керек болгон 12,5 миллион корреляциядан турган атайын скрипт менен сиз пакеттерди жасай аласыз. Башкача айтканда, 2 жуп корреляциясы бар 500 тапшырма. Жана бул тапшырма белгилүү бир ClickHouse серверинде эсептелиши керек. Анын бардык маалыматтары бар, анткени маалыматтар бирдей жана аларды ырааттуулук менен эсептей алат.

Дагы бир жолу, бул көрүнүш. Биринчиден, бул түзүмдө бизде бардык маалыматтар бар: убакыт, үлүштөр, баа. Андан кийин биз logReturn, башкача айтканда, ошол эле структурадагы маалыматтарды эсептедик, бирок баанын ордуна бизде logReturn бар. Андан кийин алар кайра жасалды, башкача айтканда, биз запастар жана баалар үчүн убакыт жана groupArray алдык. Sreplicated. Ошондон кийин, биз бир топ тапшырмаларды жаратып, аларды эсептеп чыгышы үчүн аларды ClickHouseга бердик. Жана ал иштейт.

Концепциянын далили боюнча, тапшырма кошумча тапшырма болгон, б.а., азыраак маалымат алынган. Жана үч гана сервер.

Алгачкы эки этап: Log_return эсептөө жана массивдерге ороп коюу бир саатка жакын убакытты алды.

Ал эми корреляцияны эсептөө болжол менен 50 саатты түзөт. Бирок 50 саат аздык кылат, анткени алар жумалап иштешчү. Бул чоң ийгилик болду. Эгер санап көрсөңүз, секундасына 70 жолу бул кластерде бардыгы эсептелген.

Бирок эң негизгиси, бул система иш жүзүндө эч кандай тоскоолдуксуз, башкача айтканда, дээрлик сызыктуу масштабда. Анан алар текшеришти. Аны ийгиликтүү кеңейтти.

• Туура схема - ийгиликтин жарымы. Ал эми туура схемасы бардык зарыл ClickHouse технологияларды колдонуу болуп саналат.
• Summing/AggregatingMergeTrees - бул өзгөчө учур катары абалдын сүрөтүн бириктирүүгө же кароого мүмкүндүк берген технологиялар. Жана ал көп нерсени абдан жөнөкөйлөтөт.
• Материалдык көрүнүштөр бир индекс чегин айланып өтүүгө мүмкүндүк берет. Балким, мен аны так айткан эмесмин, бирок биз журналдарды жүктөгөндө, чийки журналдар бир индекс менен таблицада, ал эми атрибут журналдары таблицада, б.а. ошол эле маалыматтар, бир гана чыпкаланган, бирок индекс толугу менен башкалар. Бул бир эле маалыматтар окшойт, бирок сорттоо ар кандай. Жана Материалдык көрүнүштөр сизге керек болсо, мындай ClickHouse чектөөсүн айланып өтүүгө мүмкүндүк берет.
• Чектөө сурамдары үчүн индекстин гранулярдуулугун азайтыңыз.
• Жана маалыматтарды акылдуу бөлүштүрүү, мүмкүн болушунча сервердин ичиндеги маалыматтарды локалдаштырууга аракет кылыңыз. Мүмкүн болушунча өтүнүчтөр локализацияны колдонушун камсыз кылууга аракет кылыңыз.

Бул кыска сөздү жыйынтыктап жатып, ClickHouse азыр коммерциялык маалымат базаларынын да, ачык булактуу маалымат базаларынын да аймагын, б.а., атайын аналитика үчүн бекем ээледи деп айта алабыз. Ал бул пейзажга толук дал келет. Анан дагы, ал акырындап башкаларды жыйып баштайт, анткени сизде ClickHouse болгондо, сизге InfiniDB керек эмес. Эгерде алар кадимки SQL колдоо көрсөтсө, Vertika жакында кереги жок болушу мүмкүн. Enjoy!

-Кабар үчүн рахмат! Абдан кызыктуу! Apache Phoenix менен салыштыруулар болгонбу?

Жок, мен эч кимди салыштырганын уккан эмесмин. Биз жана Яндекс ар кандай маалымат базалары менен бардык ClickHouse салыштырууларына көз салууга аракет кылабыз. Анткени күтүлбөгөн жерден бир нерсе ClickHouseдан ылдамыраак болуп чыкса, анда Леша Миловидов түнү менен уктай албай, тез ылдамдата баштайт. Мен мындай салыштырууну уккан эмесмин.

• (Алексей Миловидов) Apache Phoenix бул Hbase тарабынан иштетилген SQL кыймылдаткычы. Hbase негизинен ачкыч-маанилүү иш сценарийи үчүн. Ал жерде, ар бир сапта ыктыярдуу аталыштары бар тилкелердин ыктыярдуу саны болушу мүмкүн. Бул Hbase, Cassandra сыяктуу системалар жөнүндө айтууга болот. Жана так оор аналитикалык суроолор алар үчүн кадимкидей иштебейт. Же сиз ClickHouse менен эч кандай тажрыйбаңыз жок болсо, алар жакшы иштейт деп ойлошуңуз мүмкүн.

• Спасибо

  • Кутмандуу күнүң менен! Мен бул темага абдан кызыгам, анткени менде аналитикалык подсистема бар. Бирок мен ClickHouseды караганымда, ClickHouse окуяларды талдоо үчүн абдан ылайыктуу, өзгөрүлмө деген сезимди пайда кылам. Эгерде мен көптөгөн бизнес-маалыматтарды бир топ чоң таблицалар менен анализдешим керек болсо, анда ClickHouse, мен түшүнүшүм боюнча, мен үчүн абдан ылайыктуу эмеспи? Айрыкча, алар өзгөрсө. Бул туурабы же муну жокко чыгара турган мисалдар барбы?

  • Бул туура. Бул көпчүлүк адистештирилген аналитикалык маалымат базаларына тиешелүү. Алар өзгөрүлүүчү бир же бир нече чоң таблицалар жана жай өзгөрүүчү көптөгөн майда таблицалар үчүн ылайыкташтырылган. Башкача айтканда, ClickHouse Oracle сыяктуу эмес, анда бардыгын коюп, өтө татаал суроо-талаптарды түзө аласыз. ClickHouse'ту эффективдүү колдонуу үчүн сиз ClickHouseда жакшы иштегендей схема түзүшүңүз керек. Башкача айтканда, ашыкча нормалдаштыруудан алыс болуңуз, сөздүктөрдү колдонуңуз, узун шилтемелерди азыраак жасоого аракет кылыңыз. Ал эми схема ушундай жол менен курулган болсо, анда окшош бизнес-милдеттерди ClickHouseда салттуу реляциялык маалымат базасына караганда алда канча натыйжалуу чечсе болот.

Баяндама үчүн рахмат! Менин акыркы каржы иши боюнча суроом бар. Алардын аналитикасы бар болчу. Алардын кантип өйдө-төмөн жүргөнүн салыштыруу керек болчу. Сиз бул аналитика үчүн атайын системаны курганыңызды түшүнөм? Эгер эртең, мисалы, аларга бул маалыматтар боюнча башка отчет керек болсо, схеманы кайра куруп, маалыматтарды жүктөө керекпи? Башкача айтканда, суроо-талапты алуу үчүн кандайдыр бир алдын ала иштеп чыгуу үчүнбү?

Албетте, бул ClickHouse'ту абдан конкреттүү тапшырма үчүн колдонуу. Бул салттуу түрдө Hadoop ичинде чечилиши мүмкүн. Hadoop үчүн бул идеалдуу иш. Бирок Hadoop боюнча бул абдан жай. Менин максатым ClickHouse адатта такыр башка жолдор менен чечиле турган милдеттерди чече аларын көрсөтүү, бирок ошол эле учурда аны алда канча натыйжалуу аткара алат. Бул белгилүү бир иш үчүн ылайыкташтырылган. Окшош нерсе менен маселе болсо, аны да ушундай эле жол менен чечсе болору түшүнүктүү.

Түшүнүктүү. Сиз 50 саат иштетилди деп айттыңыз. Бул башынан эле, качан маалыматтарды жүктөдүңүз же жыйынтыгын алдыңызбы?

Ооба ооба.

макул сага чоң рахмат.

Бул 3 сервер кластеринде.

салам! Баяндама үчүн рахмат! Баары абдан кызыктуу. Мен функционалдуулук жөнүндө бир аз сурабайм, бирок туруктуулук жагынан ClickHouse колдонуу жөнүндө. Башкача айтканда, сизде бар беле, калыбына келтириш керек беле? Бул учурда ClickHouse өзүн кандай алып жүрөт? Сизде да реплика болгонбу? Мисалы, биз ClickHouse менен көйгөйгө туш болдук, ал дагы эле чегинен чыгып, кулап түшкөндө.

Албетте, идеалдуу системалар жок. Жана ClickHouse да өзүнүн көйгөйлөрүнө ээ. Бирок Yandex.Metrica көптөн бери иштебей жатканын уктуңуз беле? Балким, андай эмес. Ал ClickHouse боюнча 2012-2013-жылдан бери ишенимдүү иштеп келет. Мен өзүмдүн тажрыйбам жөнүндө ушуну айта алам. Бизде эч качан толук ийгиликсиздиктер болгон эмес. Кээ бир жарым-жартылай нерселер болушу мүмкүн, бирок алар бизнеске олуттуу таасир эте тургандай олуттуу болгон эмес. Бул эч качан болгон эмес. ClickHouse абдан ишенимдүү жана кокусунан бузулбайт. Бул тууралуу тынчсыздануунун кереги жок. Бул чийки нерсе эмес. Бул көптөгөн компаниялар тарабынан далилденген.

Салам! Сиз дароо маалымат схемасын ойлонушуңуз керек деп айттыңыз. Андай болуп калсачы? Менин маалыматтарым төгүлүп, төгүлүп жатат. Алты ай өттү, мен мындай жашоо мүмкүн эмес экенин түшүндүм, мен маалыматтарды кайра жүктөп, алар менен бир нерсе кылышым керек.

Бул, албетте, сиздин системаңыздан көз каранды. Муну иш жүзүндө эч токтобостон жасоонун бир нече жолу бар. Мисалы, сиз материалдаштырылган көрүнүштү түзө аласыз, анда башка маалымат структурасын жасай аласыз, эгерде ал уникалдуу түрдө картага түшүрүлсө. Башкача айтканда, ал ClickHouse аркылуу карта түзүүгө уруксат берсе, б.а. кээ бир нерселерди чыгарып, негизги ачкычты өзгөртүп, бөлүүнү өзгөртсөңүз, анда сиз Материалдаштырылган көрүнүштү жасай аласыз. Ал жерде эски маалыматтарыңыздын үстүнө жазыңыз, жаңылары автоматтык түрдө жазылат. Андан кийин жөн гана Материалдык көрүнүштү колдонууга өтүңүз, андан кийин жазууну алмаштырып, эски таблицаны өлтүрүңүз. Бул жалпысынан тынымсыз ыкма.

рахмат.

Source: www.habr.com