Effectief gebruik van ClickHouse. Alexey Milovidov (Yandex)

Omdat ClickHouse een gespecialiseerd systeem is, is het belangrijk om bij het gebruik rekening te houden met de kenmerken van de architectuur. In dit rapport zal Alexey vertellen over voorbeelden van veelgemaakte fouten bij het gebruik van ClickHouse, die tot ineffectief werk kunnen leiden. Praktische voorbeelden zullen laten zien hoe het kiezen van een of ander gegevensverwerkingsschema de prestaties in ordes van grootte kan veranderen.

Dag Allemaal! Mijn naam is Alexey, ik maak ClickHouse.

Ten eerste haast ik me om u meteen een plezier te doen, vandaag zal ik u niet vertellen wat ClickHouse is. Eerlijk gezegd ben ik het beu. Elke keer als ik zeg wat het is. En waarschijnlijk weet iedereen het al.

In plaats daarvan zal ik u vertellen welke mogelijke fouten er zijn, dat wil zeggen hoe u ClickHouse verkeerd kunt gebruiken. In feite hoeft u niet bang te zijn, want wij ontwikkelen ClickHouse als een systeem dat eenvoudig, handig en out-of-the-box werkt. Ik heb het geïnstalleerd, geen problemen.

Maar u moet er nog steeds rekening mee houden dat dit systeem gespecialiseerd is en dat u gemakkelijk een ongebruikelijk gebruiksscenario tegen kunt komen dat dit systeem uit zijn comfortzone haalt.

Dus, wat voor soort hark is er? Meestal zal ik over voor de hand liggende dingen praten. Alles is voor iedereen duidelijk, iedereen begrijpt alles en kan blij zijn dat ze zo slim zijn, en degenen die het niet begrijpen, zullen iets nieuws leren.

Het eerste en eenvoudigste voorbeeld, dat helaas vaak voorkomt, is een groot aantal inzetstukken met kleine batches, dat wil zeggen een groot aantal kleine inzetstukken.

Als we bedenken hoe ClickHouse de invoeging uitvoert, dan kunt u in één verzoek minimaal een terabyte aan gegevens verzenden. Het is geen probleem.

En laten we eens kijken wat de typische prestatie zou zijn. We hebben bijvoorbeeld een tabel met Yandex.Metrica-gegevens. Hits. 105 enkele kolommen. 700 bytes ongecomprimeerd. En we zullen op een goede manier invoegen in batches van een miljoen rijen.

We voegen MergeTree in de tabel, het blijken een half miljoen rijen per seconde te zijn. Geweldig. In een gerepliceerde tabel zal dit iets kleiner zijn, ongeveer 400 rijen per seconde.

En als je quoruminvoeging inschakelt, krijg je iets minder, maar nog steeds behoorlijke prestaties, 250 termen per seconde. Het invoegen van quorums is een ongedocumenteerde functie in ClickHouse*.

* vanaf 2020, al gedocumenteerd.

Wat gebeurt er als je iets slechts doet? We voegen één rij in de MergeTree-tabel in en krijgen 59 rijen per seconde. Dat is 10 keer langzamer. In ReplicatedMergeTree – 000 rijen per seconde. En als het quorum is ingeschakeld, blijken het 6 regels per seconde te zijn. Volgens mij is dit een soort absolute onzin. Hoe kun je zo vertragen? Ik heb zelfs op mijn T-shirt geschreven dat ClickHouse niet langzamer moet gaan werken. Maar toch gebeurt het soms.

In feite is dit onze tekortkoming. We hadden alles gemakkelijk kunnen laten werken, maar dat hebben we niet gedaan. En we hebben het niet gedaan omdat ons script dit niet nodig had. We hadden al butches. We hebben net batches ontvangen bij onze ingang en geen problemen. We plaatsen het en alles werkt prima. Maar uiteraard zijn er allerlei scenario’s mogelijk. Bijvoorbeeld als u een aantal servers heeft waarop gegevens worden gegenereerd. En ze voegen niet zo vaak gegevens in, maar ze eindigen nog steeds met frequente invoegingen. En we moeten dit op de een of andere manier vermijden.

Vanuit technisch oogpunt is het punt dat wanneer u een invoeging in ClickHouse doet, de gegevens in geen enkele geheugentabel terechtkomen. We hebben niet eens een echte logstructuur MergeTree, maar alleen een MergeTree, omdat er noch een log, noch een memTable is. We schrijven de gegevens eenvoudigweg onmiddellijk naar het bestandssysteem, al gerangschikt in kolommen. En als u 100 kolommen heeft, moeten er meer dan 200 bestanden naar een aparte map worden geschreven. Dit alles is erg omslachtig.

En de vraag rijst: “Hoe doe je dat goed?” Als de situatie zo is dat je toch op de een of andere manier gegevens in ClickHouse moet vastleggen.

Methode 1. Dit is de gemakkelijkste manier. Gebruik een soort gedistribueerde wachtrij. Kafka bijvoorbeeld. U haalt eenvoudigweg gegevens uit Kafka en batcht deze één keer per seconde. En alles komt goed, je neemt op, alles werkt prima.

De nadelen zijn dat Kafka ook een omvangrijk gedistribueerd systeem is. Ik begrijp het ook als u Kafka al in uw bedrijf heeft. Het is goed, het is handig. Maar als het niet bestaat, moet u drie keer nadenken voordat u nog een gedistribueerd systeem naar uw project sleept. En dus is het de moeite waard om alternatieven te overwegen.

Methode 2. Dit is een ouderwets alternatief en tegelijkertijd heel eenvoudig. Heeft u een soort server die uw logs genereert? En het schrijft gewoon uw logs naar een bestand. En een keer per seconde hernoemen we dit bestand bijvoorbeeld en scheuren we een nieuw bestand af. En een apart script, via cron of een daemon, neemt het oudste bestand en schrijft het naar ClickHouse. Als je eenmaal per seconde logs registreert, komt alles goed.

Maar het nadeel van deze methode is dat als jouw server waarop de logs worden gegenereerd ergens verdwijnt, de gegevens ook verdwijnen.

Methode 3. Er is nog een interessante methode, waarvoor helemaal geen tijdelijke bestanden nodig zijn. Je hebt bijvoorbeeld een soort reclamespinner of een andere interessante daemon die gegevens genereert. En u kunt een heleboel gegevens rechtstreeks in het RAM-geheugen verzamelen, in de buffer. En als er voldoende tijd is verstreken, legt u deze buffer opzij, maakt u een nieuwe en voegt u in een aparte thread in ClickHouse in wat zich al heeft verzameld.

Aan de andere kant verdwijnen de gegevens ook met kill -9. Als uw server crasht, raakt u deze gegevens kwijt. En een ander probleem is dat als u niet naar de database kunt schrijven, uw gegevens zich in het RAM-geheugen ophopen. En óf het RAM-geheugen raakt op, óf u verliest eenvoudigweg gegevens.

Methode 4. Nog een interessante methode. Heeft u een soort serverproces? En het kan gegevens onmiddellijk naar ClickHouse sturen, maar doe het in één verbinding. Ik heb bijvoorbeeld een http-verzoek verzonden met transfer-encoding: chunked met insert. En het genereert niet al te zelden stukjes; je kunt elke regel verzenden, hoewel er overhead is voor het inlijsten van deze gegevens.

In dit geval worden de gegevens echter onmiddellijk naar ClickHouse verzonden. En ClickHouse buffert ze zelf.

Maar er ontstaan ​​ook problemen. Nu verliest u gegevens, ook wanneer uw proces wordt beëindigd en als het ClickHouse-proces wordt beëindigd, omdat het een onvolledige invoeging zal zijn. En in ClickHouse zijn invoegingen atomair tot een bepaalde gespecificeerde drempel in de grootte van rijen. In principe is dit een interessante manier. Kan ook worden gebruikt.

Methode 5. Hier is nog een interessante methode. Dit is een soort door de gemeenschap ontwikkelde server voor het batchen van gegevens. Ik heb er zelf nog niet naar gekeken, dus ik kan niets garanderen. Voor ClickHouse zelf worden echter geen garanties gegeven. Dit is ook open source, maar aan de andere kant ben je misschien gewend aan een kwaliteitsstandaard die we proberen te bieden. Maar voor dit ding - ik weet het niet, ga naar GitHub, kijk naar de code. Misschien hebben ze iets normaals geschreven.

* vanaf 2020 moet ook in overweging worden genomen KittenHuis.

Methode 6. Een andere methode is het gebruik van buffertabellen. Het voordeel van deze methode is dat het heel gemakkelijk is om ermee aan de slag te gaan. Maak een buffertabel en plaats deze daarin.

Het nadeel is dat het probleem niet volledig is opgelost. Als u bij een snelheid als MergeTree gegevens moet groeperen op één batch per seconde, dan moet u bij een snelheid in een buffertabel minimaal enkele duizenden per seconde groeperen. Als het meer dan 10 per seconde is, is het nog steeds slecht. En als je het batchgewijs invoegt, zie je dat het honderdduizend regels per seconde blijken te zijn. En dit is al gebaseerd op vrij zware gegevens.

En ook buffertabellen hebben geen log. En als er iets mis is met uw server, gaan de gegevens verloren.

En als bonus kregen we onlangs bij ClickHouse de mogelijkheid om gegevens van Kafka op te halen. Er is een tafelmotor - Kafka. Je creëert gewoon. En je kunt er gematerialiseerde voorstellingen aan hangen. In dit geval zal het zelf gegevens uit Kafka extraheren en deze in de tabellen invoegen die u nodig hebt.

En wat vooral prettig is aan deze kans, is dat wij het niet waren die het deden. Dit is een gemeenschapsfunctie. En als ik ‘gemeenschapsfunctie’ zeg, meen ik dat zonder enige minachting. We hebben de code gelezen, een beoordeling gedaan en het zou goed moeten werken.

* Vanaf 2020 is er soortgelijke steun verschenen voor RabbitMQ.

Wat kan er nog meer lastig of onverwacht zijn bij het invoegen van gegevens? Als u een verzoek om waarden invoegt en enkele berekende uitdrukkingen in waarden schrijft. Now() is bijvoorbeeld ook een berekende uitdrukking. En in dit geval wordt ClickHouse gedwongen om de tolk van deze uitdrukkingen op elke regel te starten, en de prestaties zullen met ordes van grootte afnemen. Het is beter om dit te vermijden.

* op dit moment is het probleem volledig opgelost, er is geen sprake meer van prestatieregressie bij het gebruik van expressies in VALUES.

Een ander voorbeeld is wanneer er enkele problemen kunnen optreden wanneer u gegevens heeft over één batch die tot een aantal partities behoort. Standaard zijn ClickHouse-partities per maand. En als u een batch van een miljoen rijen invoegt en er zijn gegevens voor meerdere jaren, dan heeft u daar enkele tientallen partities. En dit komt overeen met het feit dat er batches zullen zijn die tientallen keren kleiner zijn, omdat ze binnenin altijd eerst in partities worden verdeeld.

* Onlangs heeft ClickHouse in de experimentele modus ondersteuning toegevoegd voor het compacte formaat van chunks en chunks in RAM met vooruitschrijflogboek, waardoor het probleem bijna volledig wordt opgelost.

Laten we nu eens kijken naar het tweede type probleem: het typen van gegevens.

Het typen van gegevens kan strikt of string zijn. String is wanneer je het net hebt gepakt en hebt aangegeven dat al je velden van het type string zijn. Dit is rot. Het is niet nodig om dit te doen.

Laten we eens kijken hoe we het op de juiste manier kunnen doen in die gevallen waarin je wilt zeggen dat we een veld of een string hebben, en laat ClickHouse het zelf uitzoeken, en ik zal er geen moeite meer voor doen. Maar het is nog steeds de moeite waard om wat moeite te doen.

We hebben bijvoorbeeld een IP-adres. In één geval hebben we het als een string opgeslagen. Bijvoorbeeld 192.168.1.1. En in een ander geval zal het een nummer van het type UInt32* zijn. 32 bits is voldoende voor een IPv4-adres.

Ten eerste worden de gegevens, vreemd genoeg, ongeveer gelijk gecomprimeerd. Er zal natuurlijk een verschil zijn, maar niet zo groot. Er zijn dus geen speciale problemen met schijf-I/O.

Maar er is een serieus verschil in processortijd en uitvoeringstijd van query's.

Laten we het aantal unieke IP-adressen tellen als deze als getallen zijn opgeslagen. Dat komt neer op 137 miljoen lijnen per seconde. Als hetzelfde in de vorm van strings is, dan 37 miljoen regels per seconde. Ik weet niet waarom dit toeval gebeurde. Deze verzoeken heb ik zelf uitgevoerd. Maar nog steeds ongeveer 4 keer langzamer.

En als je het verschil in schijfruimte berekent, dan is er ook een verschil. En het verschil is ongeveer een kwart, omdat er behoorlijk veel unieke IP-adressen zijn. En als er regels zouden zijn met een klein aantal verschillende betekenissen, dan zouden ze volgens het woordenboek gemakkelijk tot ongeveer hetzelfde volume kunnen worden gecomprimeerd.

En het viervoudige tijdsverschil ligt niet aan de weg. Misschien maakt het je niets uit natuurlijk, maar als ik zo'n verschil zie, word ik verdrietig.

Laten we naar verschillende gevallen kijken.

1. Eén geval waarin u weinig verschillende unieke waarden heeft. In dit geval gebruiken we een eenvoudige praktijk die u waarschijnlijk kent en die u voor elk DBMS kunt gebruiken. Dit is allemaal logisch, niet alleen voor ClickHouse. Schrijf gewoon numerieke identificatiegegevens in de database. En u kunt converteren naar strings en terug aan de zijkant van uw applicatie.

U hebt bijvoorbeeld een regio. En je probeert het op te slaan als een string. En daar zal het worden geschreven: Moskou en de regio Moskou. En als ik zie dat er ‘Moskou’ staat, is het niets, maar als het Moskou is, wordt het op de een of andere manier volkomen triest. Dit is hoeveel bytes.

In plaats daarvan noteren we eenvoudigweg het getal Ulnt32 en 250. We hebben 250 in Yandex, maar die van jou kan anders zijn. Voor het geval dat ik zal zeggen dat ClickHouse een ingebouwde mogelijkheid heeft om met een geobase te werken. U schrijft eenvoudigweg een map met regio's op, inclusief een hiërarchische map, d.w.z. er zal Moskou, de regio Moskou zijn en alles wat u nodig heeft. En u kunt converteren op verzoekniveau.

De tweede optie is ongeveer hetzelfde, maar met ondersteuning binnen ClickHouse. Dit is het gegevenstype Enum. Je schrijft eenvoudig alle waarden die je nodig hebt in de Enum. Type bijvoorbeeld het apparaat en schrijf daar: desktop, mobiel, tablet, tv. Er zijn in totaal 4 opties.

Het nadeel is dat je het periodiek moet veranderen. Slechts één optie toegevoegd. Laten we de tabel veranderen. In feite is het wijzigen van de tabel in ClickHouse gratis. Vooral gratis voor Enum omdat de gegevens op schijf niet veranderen. Maar toch krijgt Alter een slot* op tafel en moet hij wachten tot alle selecties zijn uitgevoerd. En pas nadat deze wijziging wordt uitgevoerd, d.w.z. er zijn nog steeds enkele ongemakken.

* in de nieuwste versies van ClickHouse is ALTER volledig non-blocking gemaakt.

Een andere optie die vrij uniek is voor ClickHouse is het koppelen van externe woordenboeken. U kunt nummers schrijven in ClickHouse en uw telefoonboeken bewaren in elk systeem dat voor u geschikt is. U kunt bijvoorbeeld gebruiken: MySQL, Mongo, Postgres. U kunt zelfs uw eigen microservice maken die deze gegevens via http verzendt. En op ClickHouse-niveau schrijft u een functie die deze gegevens van getallen naar tekenreeksen converteert.

Dit is een gespecialiseerde maar zeer efficiënte manier om een ​​join op een externe tabel uit te voeren. En er zijn twee opties. In één uitvoeringsvorm zullen deze gegevens volledig in de cache worden opgeslagen, volledig aanwezig zijn in het RAM en met enige frequentie worden bijgewerkt. En in een andere optie, als deze gegevens niet in het RAM-geheugen passen, kunt u deze gedeeltelijk in de cache opslaan.

Hier is een voorbeeld. Er is Yandex.Direct. En er is een reclamebedrijf en banners. Er zijn waarschijnlijk ongeveer tientallen miljoenen reclamebedrijven. En ze passen ongeveer in het RAM-geheugen. En er zijn miljarden spandoeken, die passen niet. En we gebruiken een in de cache opgeslagen woordenboek van MySQL.

Het enige probleem is dat het in de cache opgeslagen woordenboek prima werkt als het trefferpercentage bijna 100% bedraagt. Als het kleiner is, moet u bij het verwerken van zoekopdrachten voor elke batch gegevens feitelijk de ontbrekende sleutels nemen en de gegevens uit MySQL halen. Wat ClickHouse betreft, kan ik nog steeds garanderen dat - ja, het vertraagt ​​niet, ik zal niet over andere systemen praten.

En als bonus zijn woordenboeken een heel gemakkelijke manier om gegevens in ClickHouse met terugwerkende kracht bij te werken. Dat wil zeggen, u had een rapport over advertentiebedrijven, de gebruiker veranderde eenvoudigweg het advertentiebedrijf en in alle oude gegevens, in alle rapporten, veranderden deze gegevens ook. Als u rijen rechtstreeks naar de tabel schrijft, is het onmogelijk om ze bij te werken.

Een andere manier als je niet weet waar je de ID's voor je strings kunt krijgen. je kunt het gewoon hashen. Bovendien is de eenvoudigste optie het nemen van een 64-bit hash.

Het enige probleem is dat als de hash 64-bit is, je vrijwel zeker botsingen zult hebben. Want als daar een miljard lijnen zijn, wordt de waarschijnlijkheid al merkbaar.

En het zou niet erg goed zijn om de namen van reclamebedrijven op deze manier te hashen. Als de reclamecampagnes van verschillende bedrijven door elkaar worden gehaald, zal er iets onbegrijpelijks zijn.

En er is een simpel trucje. Toegegeven, het is ook niet erg geschikt voor serieuze gegevens, maar als iets niet erg serieus is, voeg dan gewoon de client-ID toe aan de woordenboeksleutel. En dan krijg je botsingen, maar alleen binnen één klant. En we gebruiken deze methode voor linkkaarten in Yandex.Metrica. We hebben daar URL's, we slaan hashes op. En we weten dat er natuurlijk botsingen zijn. Maar wanneer de pagina wordt weergegeven, kan de kans worden verwaarloosd dat op een pagina van een gebruiker enkele URL's aan elkaar blijven plakken en dit wordt opgemerkt.

Als bonus zijn hashes alleen voor veel bewerkingen voldoende en hoeven de strings zelf nergens te worden opgeslagen.

Een ander voorbeeld is als de tekenreeksen kort zijn, bijvoorbeeld voor websitedomeinen. Ze kunnen worden opgeslagen zoals ze zijn. Of de browsertaal ru is bijvoorbeeld 2 bytes. Natuurlijk heb ik echt medelijden met de bytes, maar maak je geen zorgen, 2 bytes zijn geen medelijden. Houd het zoals het is, maak je geen zorgen.

Een ander geval is wanneer er daarentegen veel lijnen zijn en er veel unieke in zitten, en zelfs de set potentieel onbeperkt is. Een typisch voorbeeld zijn zoektermen of URL’s. Zoekzinnen, inclusief typefouten. Laten we eens kijken hoeveel unieke zoektermen er per dag zijn. En het blijkt dat ze bijna de helft van alle evenementen uitmaken. En in dit geval zou je kunnen denken dat je de gegevens moet normaliseren, de identificatiegegevens moet tellen en deze in een aparte tabel moet plaatsen. Maar dat is niet nodig. Laat deze lijnen gewoon zoals ze zijn.

Het is beter om niets uit te vinden, want als je het apart opslaat, moet je een join doen. En deze join is op zijn best een willekeurige toegang tot het geheugen, als het nog in het geheugen past. Als het niet past, ontstaan ​​er problemen.

En als de gegevens op hun plaats worden opgeslagen, worden ze eenvoudigweg in de vereiste volgorde uit het bestandssysteem gelezen en is alles in orde.

Als u URL's of een andere complexe lange reeks heeft, is het de moeite waard om te overwegen dat u vooraf een soort uittreksel kunt berekenen en dit in een aparte kolom kunt schrijven.

Voor URL’s kunt u bijvoorbeeld het domein apart opslaan. En als je echt een domein nodig hebt, gebruik dan gewoon deze kolom, en de URL's zullen daar staan, en je raakt ze niet eens aan.

Laten we eens kijken wat het verschil is. ClickHouse heeft een gespecialiseerde functie die het domein berekent. Het is erg snel, we hebben het geoptimaliseerd. En eerlijk gezegd voldoet het niet eens aan de RFC, maar houdt het toch rekening met alles wat we nodig hebben.

En in één geval halen we eenvoudigweg de URL's op en berekenen we het domein. Dat komt neer op 166 milliseconden. En als je een kant-en-klaar domein neemt, dan blijkt dat slechts 67 milliseconden te zijn, dus bijna drie keer sneller. En het is sneller, niet omdat we wat berekeningen moeten doen, maar omdat we minder gegevens lezen.

Daarom heeft één verzoek, dat langzamer is, een hogere snelheid van gigabytes per seconde. Omdat het meer gigabytes leest. Dit zijn volkomen onnodige gegevens. Het verzoek lijkt sneller te worden uitgevoerd, maar het duurt langer om het te voltooien.

En als je kijkt naar de hoeveelheid gegevens op de schijf, blijkt dat de URL 126 megabytes is en het domein slechts 5 megabytes. Het blijkt 25 keer minder te zijn. Maar toch wordt het verzoek slechts 4 keer sneller uitgevoerd. Maar dat komt omdat de data hot zijn. En als het koud was, zou het waarschijnlijk 25 keer sneller zijn dankzij schijf-I/O.

Trouwens, als je schat hoeveel kleiner een domein is dan een URL, blijkt het ongeveer 4 keer kleiner te zijn, maar om de een of andere reden nemen de gegevens 25 keer minder in beslag op de schijf. Waarom? Door compressie. En de URL is gecomprimeerd en het domein is gecomprimeerd. Maar vaak bevat de URL een hoop onzin.

En uiteraard loont het om de juiste datatypen te gebruiken die specifiek zijn ontworpen voor de gewenste waarden of die geschikt zijn. Als u in IPv4 werkt, sla dan UInt32* op. Indien IPv6, dan FixedString(16), omdat het IPv6-adres 128 bits is, d.w.z. direct opgeslagen in binair formaat.

Maar wat als je soms IPv4-adressen hebt en soms IPv6? Ja, u kunt beide opslaan. Eén kolom voor IPv4, een andere voor IPv6. Uiteraard is er een optie om IPv4 in IPv6 weer te geven. Dit zal ook werken, maar als je vaak een IPv4-adres nodig hebt bij verzoeken, dan zou het leuk zijn om dit in een aparte kolom te zetten.

* ClickHouse heeft nu afzonderlijke IPv4- en IPv6-gegevenstypen die gegevens net zo efficiënt opslaan als getallen, maar ze net zo handig weergeven als tekenreeksen.

Het is ook belangrijk op te merken dat het de moeite waard is om de gegevens vooraf te verwerken. U ontvangt bijvoorbeeld enkele onbewerkte logboeken. En misschien moet je ze niet meteen in ClickHouse zetten, al is het heel verleidelijk om niets te doen en alles werkt. Maar het is nog steeds de moeite waard om de berekeningen uit te voeren die mogelijk zijn.

Bijvoorbeeld browserversie. Op een nabijgelegen afdeling, waar ik niet met de vinger naar wil wijzen, wordt de browserversie als volgt opgeslagen, dat wil zeggen als een string: 12.3. En om vervolgens een rapport te maken, nemen ze deze string en verdelen deze in een array, en dan in het eerste element van de array. Natuurlijk gaat alles langzamer. Ik vroeg waarom ze dit doen. Ze vertelden me dat ze niet van voortijdige optimalisatie houden. En ik hou niet van voortijdige pessimisatie.

In dit geval zou het dus juister zijn om het in 4 kolommen te verdelen. Wees hier niet bang, want dit is ClickHouse. ClickHouse is een kolomvormige database. En hoe nettere kleine kolommen, hoe beter. Er zullen 5 browserversies zijn, maak 5 kolommen. Dit is goed.

Laten we nu eens kijken wat we moeten doen als je veel hele lange strings, hele lange arrays hebt. Ze hoeven helemaal niet in ClickHouse te worden opgeslagen. In plaats daarvan kunt u alleen een identificatie in ClickHouse opslaan. En plaats deze lange rijen in een ander systeem.

Een van onze analysediensten heeft bijvoorbeeld enkele gebeurtenisparameters. En als er veel parameters zijn voor evenementen, bewaren we gewoon de eerste 512 die we tegenkomen, want 512 is niet jammer.

En als u niet kunt beslissen over uw gegevenstypes, dan kunt u gegevens ook vastleggen in ClickHouse, maar dan in een tijdelijke tabel van het type Log, speciaal voor tijdelijke gegevens. Hierna kunt u analyseren welke waardenverdeling u daar heeft, wat er in het algemeen is, en de juiste typen creëren.

*ClickHouse heeft nu een gegevenstype Lage kardinaliteit waarmee u snaren efficiënt en met minder inspanning kunt opslaan.

Laten we nu eens naar een ander interessant geval kijken. Soms werken dingen vreemd voor mensen. Ik kom binnen en zie dit. En het lijkt er meteen op dat dit is gedaan door een zeer ervaren, slimme beheerder die uitgebreide ervaring heeft met het opzetten van MySQL versie 3.23.

Hier zien we duizend tabellen, die elk de rest registreren van wie weet wat door duizend deelt.

In principe respecteer ik de ervaring van anderen, inclusief het begrip van het lijden dat door deze ervaring kan worden verkregen.

En de redenen zijn min of meer duidelijk. Dit zijn oude stereotypen die zich mogelijk hebben opgehoopt tijdens het werken met andere systemen. MyISAM-tabellen hebben bijvoorbeeld geen geclusterde primaire sleutel. En deze manier om gegevens te verdelen kan een wanhopige poging zijn om dezelfde functionaliteit te krijgen.

Een andere reden is dat het moeilijk is om wijzigingsbewerkingen uit te voeren op grote tafels. Alles zal worden geblokkeerd. Hoewel dit probleem in moderne versies van MySQL niet langer zo ernstig is.

Of bijvoorbeeld microsharding, maar daarover later meer.

In ClickHouse is dit niet nodig, omdat ten eerste de primaire sleutel is geclusterd, de gegevens zijn geordend op basis van de primaire sleutel.

En soms vragen mensen mij: “Hoe variëren de prestaties van bereikzoekopdrachten in ClickHouse, afhankelijk van de tabelgrootte?” Ik zeg dat er helemaal niets verandert. U hebt bijvoorbeeld een tabel met een miljard rijen en u leest een bereik van een miljoen rijen. Alles is in orde. Als er een biljoen rijen in een tabel staan ​​en je leest een miljoen rijen, dan zal het bijna hetzelfde zijn.

En ten tweede zijn allerlei zaken zoals handmatige partities niet vereist. Als je naar binnen gaat en kijkt naar wat er in het bestandssysteem staat, zul je zien dat de tabel behoorlijk belangrijk is. En er zitten zoiets als scheidingswanden binnenin. Dat wil zeggen: ClickHouse doet alles voor u en u hoeft er niet onder te lijden.

Wijzigen in ClickHouse is gratis als u de kolom wijzigt/verwijdert.

En je moet geen kleine tabellen maken, want als je 10 rijen of 10 rijen in een tabel hebt, dan maakt het helemaal niet uit. ClickHouse is een systeem dat de doorvoer optimaliseert, niet de latentie, dus het heeft geen zin om 000 regels te verwerken.

Het is juist om één grote tafel te gebruiken. Weg met oude stereotypen, alles komt goed.

En als bonus hebben we nu in de nieuwste versie de mogelijkheid om een ​​willekeurige partitiesleutel te maken om allerlei onderhoudswerkzaamheden op individuele partities uit te voeren.

U hebt bijvoorbeeld veel kleine tabellen nodig. Wanneer er bijvoorbeeld tussenliggende gegevens moeten worden verwerkt, ontvangt u stukjes en moet u er een transformatie op uitvoeren voordat u naar de finaletabel schrijft. Voor dit geval is er een prachtige tafelengine - StripeLog. Het lijkt een beetje op TinyLog, maar dan beter.

*nu heeft ClickHouse dat ook invoer van tabelfuncties.

Een ander antipatroon is microsharding. Je moet bijvoorbeeld gegevens delen en je hebt 5 servers, en morgen zullen er 6 servers zijn. En u denkt na over hoe u deze gegevens opnieuw in evenwicht kunt brengen. En in plaats daarvan breek je het niet in 5 scherven, maar in 1 scherven. En dan wijst u elk van deze microshards toe aan een afzonderlijke server. En je krijgt bijvoorbeeld 000 ClickHouses op één server. Afzonderlijke instances op afzonderlijke poorten of afzonderlijke databases.

Maar dit is niet erg goed in ClickHouse. Omdat zelfs één ClickHouse-instantie alle beschikbare serverbronnen probeert te gebruiken om één verzoek te verwerken. Dat wil zeggen, je hebt een soort server en deze heeft bijvoorbeeld 56 processorkernen. U voert een query uit die één seconde duurt en die 56 kernen gebruikt. En als je daar 200 ClickHouses op één server plaatst, dan blijken er 10 threads te starten. Over het algemeen zal alles erg slecht zijn.

Een andere reden is dat de verdeling van het werk over deze instanties ongelijk zal zijn. Sommigen zullen eerder klaar zijn, anderen zullen later klaar zijn. Als dit allemaal in één keer zou gebeuren, zou ClickHouse zelf uitzoeken hoe de gegevens correct over de threads konden worden verdeeld.

En een andere reden is dat u communicatie tussen processors via TCP zult hebben. De gegevens zullen moeten worden geserialiseerd, gedeserialiseerd, en dit zijn een groot aantal microshards. Het zal simpelweg niet effectief werken.

Nog een antipatroon, hoewel het nauwelijks een antipatroon kan worden genoemd. Dit is een grote hoeveelheid pre-aggregatie.

Over het algemeen is pre-aggregatie goed. Je had een miljard rijen, je hebt ze samengevoegd en het werden 1 rijen, en nu wordt de zoekopdracht onmiddellijk uitgevoerd. Alles is geweldig. Je kan dit doen. En hiervoor heeft zelfs ClickHouse een speciaal tabeltype, AggregatingMergeTree, dat incrementele aggregatie uitvoert wanneer gegevens worden ingevoegd.

Maar er zijn momenten waarop je denkt dat we dit soort gegevens en dit soort gegevens zullen samenvoegen. En op een naburige afdeling, ik wil ook niet zeggen welke, gebruiken ze SummingMergeTree-tabellen om samen te vatten op basis van de primaire sleutel, en er worden ongeveer twintig kolommen gebruikt als de primaire sleutel. Voor de zekerheid heb ik de namen van sommige kolommen gewijzigd vanwege geheimhouding, maar dat is het wel zo'n beetje.

En dergelijke problemen ontstaan. Ten eerste neemt uw datavolume niet te veel af. Het neemt bijvoorbeeld drie keer af. Drie keer zou een goede prijs zijn om de onbeperkte analysemogelijkheden te kunnen veroorloven die ontstaan ​​als uw gegevens niet worden samengevoegd. Als de gegevens worden samengevoegd, krijg je in plaats van analyses alleen maar zielige statistieken.

En wat is er zo speciaal aan? Feit is dat deze mensen van de aangrenzende afdeling soms vragen om nog een kolom aan de primaire sleutel toe te voegen. Dat wil zeggen, we hebben de gegevens op deze manier samengevoegd, maar nu willen we iets meer. Maar ClickHouse heeft geen alternatieve primaire sleutel. Daarom moeten we enkele scripts in C++ schrijven. En ik hou niet van scripts, ook al zijn ze in C++.

En als je kijkt naar waar ClickHouse voor is gemaakt, dan zijn niet-geaggregeerde gegevens precies het scenario waarvoor het is geboren. Als u ClickHouse gebruikt voor niet-geaggregeerde gegevens, dan doet u het goed. Als je alles bij elkaar optelt, is dit soms te vergeven.

Een ander interessant geval zijn zoekopdrachten in een oneindige lus. Soms ga ik naar een productieserver en kijk daar naar de showproceslijst. En elke keer ontdek ik dat er iets vreselijks gebeurt.

Bijvoorbeeld zoals dit. Het is meteen duidelijk dat alles in één verzoek kan worden gedaan. Schrijf gewoon de URL erin en de lijst daar.

Waarom zijn veel van dergelijke zoekopdrachten in een eindeloze lus slecht? Als er geen index wordt gebruikt, zult u meerdere keren dezelfde gegevens passeren. Maar als de index bijvoorbeeld wordt gebruikt, heb je een primaire sleutel voor ru en schrijf je daar url = iets. En je denkt dat als er maar één URL uit de tabel wordt gelezen, alles goed komt. Maar eigenlijk niet. Omdat ClickHouse alles in batches doet.

Wanneer hij een bepaald bereik aan gegevens moet lezen, leest hij iets meer, omdat de index in ClickHouse schaars is. Met deze index kunt u niet één individuele rij in de tabel vinden, maar alleen een bepaald bereik. En de gegevens worden in blokken gecomprimeerd. Om één regel te kunnen lezen, moet je het hele blok nemen en het losmaken. En als u een heleboel query's uitvoert, is er veel overlap en moet u steeds opnieuw een hoop werk doen.

En als bonus kun je opmerken dat je in ClickHouse niet bang hoeft te zijn om zelfs megabytes en zelfs honderden megabytes over te zetten naar de IN-sectie. Ik herinner me uit onze praktijk dat als we in MySQL een aantal waarden naar de IN-sectie overbrengen, we bijvoorbeeld 100 megabytes van sommige getallen daar overbrengen, MySQL 10 gigabytes aan geheugen opslokt en er verder niets mee gebeurt, alles werkt slecht.

En de tweede is dat als uw zoekopdrachten in ClickHouse een index gebruiken, deze altijd niet langzamer is dan een volledige scan, dat wil zeggen dat als u bijna de hele tabel moet lezen, deze opeenvolgend wordt uitgevoerd en de hele tabel leest. Over het algemeen zal hij het zelf uitzoeken.

Maar toch zijn er enkele moeilijkheden. Bijvoorbeeld het feit dat IN met een subquery de index niet gebruikt. Maar dit is ons probleem en we moeten het oplossen. Er is hier niets fundamenteels. Wij repareren het*.

En nog iets interessants is dat als je een heel lang verzoek hebt en de verwerking van gedistribueerde verzoeken aan de gang is, dit zeer lange verzoek zonder compressie naar elke server wordt verzonden. Bijvoorbeeld 100 megabytes en 500 servers. En dienovereenkomstig krijgt u 50 gigabyte overgedragen via het netwerk. Het wordt verzonden en dan wordt alles met succes voltooid.

* al in gebruik; Alles werd zoals beloofd opgelost.

En een vrij algemeen geval is wanneer verzoeken afkomstig zijn van de API. U hebt bijvoorbeeld een soort van uw eigen service gemaakt. En als iemand jouw dienst nodig heeft, dan open je de API en zie je letterlijk twee dagen later dat er iets onbegrijpelijks gebeurt. Alles is overbelast en er komen vreselijke verzoeken binnen die nooit hadden mogen gebeuren.

En er is maar één oplossing. Als je de API hebt geopend, moet je deze knippen. Voer bijvoorbeeld een soort quota in. Er zijn geen andere normale opties. Anders schrijven ze meteen een script en ontstaan ​​er problemen.

En ClickHouse heeft een speciale functie: quotaberekening. Bovendien kunt u uw quotasleutel overdragen. Dit is bijvoorbeeld de interne gebruikers-ID. En voor elk van hen zullen de quota onafhankelijk worden berekend.

Nu nog iets interessants. Dit is handmatige replicatie.

Ik ken veel gevallen waarin mensen, ondanks dat ClickHouse ingebouwde replicatieondersteuning heeft, ClickHouse handmatig repliceren.

Wat is het principe? U beschikt over een pijplijn voor gegevensverwerking. En het werkt onafhankelijk, bijvoorbeeld in verschillende datacenters. U schrijft dezelfde gegevens op dezelfde manier in ClickHouse. Het is waar dat de praktijk leert dat de gegevens nog steeds uiteen zullen lopen vanwege bepaalde functies in uw code. Ik hoop dat het in de jouwe zit.

En af en toe zul je nog steeds handmatig moeten synchroniseren. Beheerders voeren bijvoorbeeld één keer per maand rsync uit.

In feite is het veel eenvoudiger om de replicatie te gebruiken die in ClickHouse is ingebouwd. Maar er kunnen enkele contra-indicaties zijn, omdat u hiervoor ZooKeeper moet gebruiken. Ik zal niets slechts zeggen over ZooKeeper, in principe werkt het systeem, maar het komt voor dat mensen het niet gebruiken vanwege Java-fobie, omdat ClickHouse zo'n goed systeem is, geschreven in C++, dat je kunt gebruiken en alles komt goed. En ZooKeeper is in Java. En op de een of andere manier wil je niet eens kijken, maar dan kun je handmatige replicatie gebruiken.

ClickHouse is een praktisch systeem. Ze houdt rekening met jouw wensen. Als u handmatige replicatie hebt, kunt u een gedistribueerde tabel maken die naar uw handmatige replica's kijkt en daartussen een failover uitvoert. En er is zelfs een speciale optie waarmee je flops kunt vermijden, zelfs als je lijnen systematisch uiteenlopen.

Er kunnen zich nog meer problemen voordoen als u primitieve tabelengines gebruikt. ClickHouse is een constructor die een aantal verschillende tabelengines heeft. Gebruik voor alle ernstige gevallen, zoals beschreven in de documentatie, tabellen uit de MergeTree-familie. En al de rest - dit is zo, voor individuele gevallen of voor tests.

In een MergeTree-tabel hoeft u geen datum en tijd te hebben. Je kunt het nog steeds gebruiken. Als er geen datum en tijd is, schrijf dan dat de standaardwaarde 2000 is. Dit zal werken en vereist geen middelen.

En in de nieuwe versie van de server kunt u zelfs opgeven dat u over aangepaste partities beschikt zonder partitiesleutel. Het zal hetzelfde zijn.

Aan de andere kant kunt u primitieve tabelengines gebruiken. Vul bijvoorbeeld eenmalig de gegevens in en kijk, draai en verwijder. U kunt Logboek gebruiken.

Of het opslaan van kleine volumes voor tussentijdse verwerking is StripeLog of TinyLog.

Geheugen kan worden gebruikt als de hoeveelheid gegevens klein is en u eenvoudig iets in het RAM-geheugen kunt rommelen.

ClickHouse houdt niet echt van opnieuw genormaliseerde gegevens.

Hier is een typisch voorbeeld. Dit is een groot aantal URL's. Je zet ze in de volgende tabel. En toen besloten ze samen met hen JOIN te doen, maar dit zal in de regel niet werken, omdat ClickHouse alleen Hash JOIN ondersteunt. Als er niet genoeg RAM is voor veel data die verbonden moeten worden, dan zal JOIN niet werken*.

Als de gegevens een hoge kardinaliteit hebben, hoeft u zich geen zorgen te maken. Sla ze op in een gedenormaliseerde vorm; de URL's staan ​​direct op hun plaats in de hoofdtabel.

* en nu heeft ClickHouse ook een merge-join, en het werkt in omstandigheden waarin tussenliggende gegevens niet in het RAM passen. Maar dit is niet effectief en de aanbeveling blijft van kracht.

Nog een paar voorbeelden, maar ik betwijfel nu al of ze anti-patroon zijn of niet.

ClickHouse heeft één bekende fout. Hij weet niet hoe hij moet updaten*. In sommige opzichten is dit zelfs goed. Als u belangrijke gegevens heeft, bijvoorbeeld de boekhouding, kan niemand deze verzenden, omdat er geen updates zijn.

* ondersteuning voor updaten en verwijderen in batchmodus is al lang geleden toegevoegd.

Maar er zijn enkele speciale manieren waarop updates mogelijk zijn alsof ze op de achtergrond plaatsvinden. Bijvoorbeeld tabellen zoals ReplaceMergeTree. Ze maken updates tijdens samenvoegingen op de achtergrond. U kunt dit forceren met behulp van de optimalisatietabel. Maar doe dit niet te vaak, omdat het de partitie volledig zal overschrijven.

Gedistribueerde JOIN's in ClickHouse worden ook slecht afgehandeld door de queryplanner.

Slecht, maar soms oké.

ClickHouse alleen gebruiken om gegevens terug te lezen met select*.

Ik zou ClickHouse niet aanbevelen voor omslachtige berekeningen. Maar dit is niet helemaal waar, omdat we al afstand nemen van deze aanbeveling. En we hebben onlangs de mogelijkheid toegevoegd om machine learning-modellen toe te passen in ClickHouse - Catboost. En het stoort me omdat ik denk: “Wat een gruwel. Dit is het aantal cycli per byte dat blijkt! Ik haat het echt om klokken aan bytes te verspillen.

Maar wees niet bang, installeer ClickHouse, alles komt goed. Als er iets is, hebben we een gemeenschap. Trouwens, de gemeenschap ben jij. En als je problemen hebt, kun je in ieder geval naar onze chat gaan, en hopelijk zullen ze je helpen.

vragen

Bedankt voor het rapport! Waar kan ik klagen over het vastlopen van ClickHouse?

U kunt nu bij mij persoonlijk een klacht indienen.

Ik ben onlangs begonnen met het gebruik van ClickHouse. Ik heb de cli-interface onmiddellijk laten vallen.

Jij hebt geluk.

Even later crashte ik de server met een kleine selectie.

Je hebt talent.

Ik opende een GitHub-bug, maar deze werd genegeerd.

Laten we eens kijken.

Alexey heeft me misleid om het rapport bij te wonen en beloofde me te vertellen hoe je toegang krijgt tot de gegevens erin.

Heel simpel.

Dit besefte ik gisteren. Meer details.

Er zijn daar geen vreselijke trucs. Er is alleen blok-voor-blok-compressie. De standaardinstelling is LZ4, u kunt ZSTD* inschakelen. Blokken van 64 kilobytes tot 1 megabyte.

* er is ook ondersteuning voor gespecialiseerde compressiecodecs die in een keten met andere algoritmen kunnen worden gebruikt.

Zijn de blokken slechts ruwe data?

Niet helemaal rauw. Er zijn arrays. Als u een numerieke kolom heeft, worden de getallen in een rij in een array geplaatst.

Het is duidelijk.

Alexey, een voorbeeld met uniqExact over IP's, dat wil zeggen het feit dat uniqExact er langer over doet om met regels te berekenen dan met cijfers, enzovoort. Wat als we tijdens het proeflezen een schijnbeweging met onze oren maken en casten? Dat wil zeggen, je lijkt te hebben gezegd dat het op onze schijf niet veel anders is. Als we regels van schijf lezen en casten, zullen onze aggregaten dan sneller zijn of niet? Of zullen we hier nog een beetje winnen? Het lijkt mij dat je dit hebt getest, maar dit om de een of andere reden niet in de benchmark hebt aangegeven.

Ik denk dat het langzamer zal zijn dan zonder casten. In dit geval moet het IP-adres uit de tekenreeks worden geparseerd. Uiteraard is bij ClickHouse ook onze IP-adresparsering geoptimaliseerd. We hebben heel hard ons best gedaan, maar daar heb je de getallen geschreven in tienduizendste vorm. Heel oncomfortabel. Aan de andere kant zal de uniqExact-functie langzamer werken op strings, niet alleen omdat dit strings zijn, maar ook omdat er een andere specialisatie van het algoritme is geselecteerd. Strings worden simpelweg anders verwerkt.

Wat als we een primitiever gegevenstype nemen? We hebben bijvoorbeeld de gebruikers-ID opgeschreven, die we erin hebben, deze als een regel opgeschreven en vervolgens door elkaar gegooid, wordt dit leuker of niet?

Ik betwijfel. Ik denk dat het nog treuriger zal zijn, want het ontleden van cijfers is tenslotte een serieus probleem. Het lijkt mij dat deze collega zelfs een rapport heeft gegeven over hoe moeilijk het is om getallen in tienduizendste vorm te ontleden, maar misschien ook niet.

Alexey, hartelijk dank voor het rapport! En heel erg bedankt voor ClickHouse! Ik heb een vraag over plannen. Zijn er plannen voor een functie om woordenboeken onvolledig bij te werken?

Dat wil zeggen, een gedeeltelijke herstart?

Ja Ja. Zoals de mogelijkheid om daar een MySQL-veld in te stellen, d.w.z. achteraf te updaten, zodat alleen deze gegevens worden geladen als het woordenboek erg groot is.

Een zeer interessante functie. En ik denk dat iemand het in onze chat heeft voorgesteld. Misschien was jij het zelfs wel.

Ik denk het niet.

Mooi, nu blijkt dat er twee verzoeken zijn. En je kunt er langzaam aan beginnen. Maar ik wil je meteen waarschuwen dat deze functie vrij eenvoudig te implementeren is. Dat wil zeggen, in theorie hoeft u alleen maar het versienummer in de tabel te schrijven en vervolgens te schrijven: versie minder dan zo en zo. Dit betekent dat wij dit hoogstwaarschijnlijk aan liefhebbers gaan aanbieden. Bent u een liefhebber?

Ja, maar helaas niet in C++.

Kunnen uw collega's schrijven in C++?

Ik zal iemand vinden.

Geweldig*.

* de functie is twee maanden na het rapport toegevoegd - de auteur van de vraag heeft deze ontwikkeld en de zijne verzonden pull verzoek.

Dank je wel!

Hallo! Bedankt voor het rapport! U zei dat ClickHouse zeer goed is in het verbruiken van alle beschikbare middelen. En de spreker naast Luxoft sprak over zijn oplossing voor Russian Post. Hij zei dat ze ClickHouse erg leuk vonden, maar dat ze het niet gebruikten in plaats van hun belangrijkste concurrent, juist omdat het de hele CPU in beslag nam. En ze konden het niet in hun architectuur integreren, in hun ZooKeeper met dockers. Is het mogelijk om ClickHouse op de een of andere manier te beperken, zodat het niet alles verbruikt wat beschikbaar komt?

Ja, het is mogelijk en heel eenvoudig. Als je minder kernen wilt verbruiken, schrijf dan gewoon set max_threads = 1. En dat is alles, het zal het verzoek in één kern uitvoeren. Bovendien kunt u voor verschillende gebruikers verschillende instellingen opgeven. Dus geen probleem. En vertel je collega’s van Luxoft dat het niet goed is dat ze deze instelling niet in de documentatie hebben gevonden.

Alexey, hallo! Ik wil graag een vraag stellen over deze vraag. Dit is niet de eerste keer dat ik hoor dat veel mensen ClickHouse beginnen te gebruiken als opslag voor logbestanden. Bij de melding zegt u dit niet te doen, dat wil zeggen dat u geen lange strings hoeft op te slaan. Wat denk jij ervan?

Ten eerste zijn logs in de regel geen lange reeksen. Er zijn uiteraard uitzonderingen. Een service die in Java is geschreven, genereert bijvoorbeeld een uitzondering en deze wordt geregistreerd. En zo verder in een eindeloze lus, en de ruimte op de harde schijf raakt op. De oplossing is heel eenvoudig. Als de lijnen erg lang zijn, knip ze dan af. Wat betekent lang? Tientallen kilobytes zijn slecht*.

* in de nieuwste versies van ClickHouse is “adaptieve indexgranulariteit” ingeschakeld, waardoor het probleem van het opslaan van lange rijen grotendeels wordt geëlimineerd.

Is een kilobyte normaal?

Het is normaal.

Hallo! Bedankt voor het rapport! Ik heb hier al naar gevraagd in de chat, maar ik weet niet meer of ik antwoord heb gekregen. Zijn er plannen om de WITH-sectie op de een of andere manier uit te breiden op de manier van CTE?

Nog niet. Onze MET-sectie is enigszins frivool. Het is als een kleine functie voor ons.

Ik begrijp. Bedankt!

Bedankt voor het rapport! Heel interessant! Mondiale vraag. Zijn er plannen om de verwijdering van gegevens aan te passen, misschien in de vorm van een soort stubs?

Nodig. Dit is onze eerste taak in onze wachtrij. We denken nu actief na over hoe we alles correct kunnen doen. En je zou op het toetsenbord moeten drukken*.

* drukte op de knoppen op het toetsenbord en deed alles.

Zal dit op de een of andere manier de systeemprestaties beïnvloeden of niet? Zal het inbrengen net zo snel gaan als nu?

Misschien zullen de verwijderingen zelf en de updates zelf erg zwaar zijn, maar dit heeft geen invloed op de prestaties van selecties of de prestaties van invoegingen.

En nog een klein vraagje. Tijdens de presentatie sprak u over de primaire sleutel. Dienovereenkomstig hebben we een partitie, die standaard maandelijks is, correct? En als we een datumbereik instellen dat in een maand past, wordt alleen deze partitie gelezen, toch?

Да.

Een vraag. Als we geen enkele primaire sleutel kunnen selecteren, is het dan correct om dit specifiek te doen volgens het veld "Datum", zodat er op de achtergrond minder herschikking van deze gegevens plaatsvindt, zodat deze op een meer ordelijke manier passen? Als u geen bereikquery's heeft en u zelfs geen primaire sleutel kunt selecteren, is het dan de moeite waard om een ​​datum in de primaire sleutel te plaatsen?

Да.

Misschien is het zinvol om een ​​veld in de primaire sleutel te plaatsen waardoor de gegevens beter worden gecomprimeerd als deze op dit veld worden gesorteerd. Bijvoorbeeld gebruikers-ID. Gebruiker gaat bijvoorbeeld naar dezelfde site. Voer in dit geval het gebruikers-ID en de tijd in. En dan worden uw gegevens beter gecomprimeerd. Wat de datum betreft: als u echt geen bereikquery's over datums heeft en nooit heeft, hoeft u de datum niet in de primaire sleutel te plaatsen.

OK dank u zeer!

Bron: www.habr.com