Lees:MySQL-partitioneringsbeperkingen
1.) FK's worden niet ondersteund op gepartitioneerde tabellen.
- Eén optie is om een opgeslagen procedure te maken die het record invoegt/bijwerkt en om binnen de procedure te verifiëren dat het doorgegeven gebruikers-ID aanwezig is in uw gebruikerstabel voordat het invoegen plaatsvindt. U dient de machtigingen op de tabel zo in te stellen dat alleen de SP mag updaten en invoegen om toepassingen en/of gebruikers toe te staan de controle achter de hand te houden. U moet ook voorzorgsmaatregelen nemen bij het verwijderen van gebruikers uit de gebruikerstabel.
2.) Welke kolom u voor partitionering gebruikt, hangt af van hoe u de tabel opent. Als uw zoekopdrachten altijd gebaseerd zijn op voertuignr., dan is het waarschijnlijk logisch om een hash-partitie op die kolom te maken. Als je vragen stelt of meer rapporteert over iets als "welke voertuigen zijn deze maand toegevoegd" of als je partities wilt "uitrollen" als ze een bepaalde leeftijd bereiken, dan is partitioneren op datum misschien de beste keuze. Dit is iets wat je moet beslissen op basis van je gebruik.
3.) Zie de link hierboven voor meer informatie.
Bewerken op basis van gebruikersvraag:
Elke 3 seconden een record invoegen is niet veel doorvoer. Zorg ervoor dat u een primaire sleutel op uw gebruikerstabel heeft zodat de controle binnen de procedure efficiënt kan worden uitgevoerd. (Dit is zelfs waar als FK's werden ondersteund) De DB zou deze controle achter de schermen voor je doen als je ondersteuning had voor FK's, dus in die zin doet het je geen pijn. Als de controle een knelpunt wordt, voelt u misschien de behoefte om deze te laten vallen en mogelijk foutieve gebruikers-ID's te melden als een nachtelijk batchproces, maar als uw gebruikerstabel relatief klein is en correct is geïndexeerd, zie ik niet dat dit een probleem.
Een andere optie zou zijn om de partitionering handmatig uit te voeren (d.w.z. sharding) met gepartitioneerde of niet-gepartitioneerde tabellen. Met de niet-gepartitioneerde tabellen kunt u natuurlijk native externe sleutels gebruiken. U zou uw voertuigtabel bijvoorbeeld in meerdere tabellen opsplitsen, zoals:(ervan uitgaande dat u het voertuigNee als de "sleutel" wilt gebruiken)
VoertuigenNosLessThan1000
VoertuigenNosLessThan2000
VoertuigenNosLessThan...
VoertuigenNosLessThanMAX
Hier wil je waarschijnlijk weer een SP hebben zodat de applicatie/gebruiker niets van de tabellen hoeft te weten. De SP zou verantwoordelijk zijn voor het invoegen/bijwerken van de juiste tabel op basis van het ingevoerde voertuignr. U zou ook een SP willen voor het selecteren van gegevens, zodat de app/gebruiker de tabel niet hoeft te kennen om uit te kiezen. Voor gemakkelijke toegang tot alle gegevens kunt u een weergave maken waarin alle tabellen worden samengevoegd.
Merk op dat een voordeel hiervan is dat MyISAM momenteel een volledige gepartitioneerde tabel vergrendelt tijdens updates, niet alleen de partitie die wordt bijgewerkt. Door een tabel op deze manier te sharden, wordt die twist weggenomen, omdat de tabellen zelf de "partities" zijn.
Op basis van de beperkte gegevens die ik heb over wat u doet, zou ik waarschijnlijk 2 opgeslagen procedures schrijven, 1 voor het selecteren van de gegevens en 1 voor het bijwerken/invoegen van de gegevens, en uw toepassing deze laten gebruiken voor alle toegang. Dan zou ik eerst de reguliere partitionering via hash op vehicleNo proberen terwijl ik de user_id-sleutel binnen de procedure afdwing. Als dit een probleem wordt, kunt u eenvoudig migreren naar sharding van de gegevens over meerdere tabellen zonder dat u de toepassing hoeft te wijzigen, omdat alle logica voor het ophalen en bijwerken van de gegevens zich in de SP's bevindt.