A trick for safely using Golang Maps more efficiently

Sdílet
Vložit
  • čas přidán 25. 03. 2024
  • In this video I’ll show you how you can make your concurrent applications actually more concurrent safe by using sync mutexes and vertical sharding.
    🌱 Check the "Golang Essentials" Playlist here: • Advanced Golang
    👉 Join the private community to level up as software engineer: selfmadeengineer.com
    📢 We're building a Discord community, come and join
    / discord
    Hope you liked and thanks for watching!
    #golang
    Video titles ideas (for the algo):
    Golang maps explained
    Safely use golang maps
    Concurrency problems in golang maps

Komentáře • 30

  • @0runny
    @0runny Před měsícem

    It would be great if you could please do a follow up video demonstrating the actual performance improvements of this solution using benchmarks.

  • @dv_xl
    @dv_xl Před 2 měsíci +2

    A few notes:
    * You should add generics to make this structure reusable. That would be a cool follow up video.
    * From my experience in production environments, sharding is not a silver bullet. Often hotspots develop and you should carefully examine your access patterns, in many cases a sync.Map will perform better (for single write high read cases in a cache)
    * I'd advise people to find existing implementations of these types of structures rather than re-implement them, just because there can be some nice advantages to other ones.
    Source: been using go professionally for >5 ys

    • @rafael.aloizio1769
      @rafael.aloizio1769 Před 2 měsíci

      hey sir can I have your gh for reference?

    • @dv_xl
      @dv_xl Před 2 měsíci

      @@rafael.aloizio1769 this doxxs me so you need to give me an email or something to send it to. but there's not much interesting on it, my work is closed source unfortunately

  • @LightningMcCream
    @LightningMcCream Před 3 měsíci +1

    Saves me from having to use some external solution for my structured data,, thanks for saving me from a possible data race!

  • @favorite_engineer
    @favorite_engineer Před 3 měsíci +1

    Very helpful content

  • @coder415
    @coder415 Před 2 měsíci +1

    in a production ready golang app map needs three things at the same time: 1) it should be thread safe 2) auto or manuel shrinking feature. otherwise memory leak problem will arise 3) we need a range method for iterating over key and values

    • @dejanduh2645
      @dejanduh2645 Před 2 měsíci

      How would you implement shrinking the map?

  • @bruno8ribeiro
    @bruno8ribeiro Před 2 měsíci +1

    Boa dica!

  • @buffer0xaa555
    @buffer0xaa555 Před 3 měsíci +1

    Thank you for sharing this content with us. Be blessed.

  • @AK-vx4dy
    @AK-vx4dy Před 2 měsíci +1

    Very nice content, clear practical examples.
    I still in two minds if some things should be explained more or not, but in current times it is not necessary i think.
    I don't know much about Go but wait group interface still perplexing me 😅

    • @TiagoTaquelim
      @TiagoTaquelim  Před 2 měsíci +1

      Hey! Glad you liked it!
      Yhee, I have a tendency to make videos a bit huge so I'm making some smaller now so I can give as much value in a short amount of time. Sometimes it means cutting corners.
      However one of the next videos next month will be on Golang interfaces!

    • @AK-vx4dy
      @AK-vx4dy Před 2 měsíci +1

      @@TiagoTaquelim In times of chat gpt & Internet in my honest opinion cutting corners don't lower the value of content, people who are really interested easily obtain missing parts of puzzle and will appreciate sticking to the main topic

    • @TiagoTaquelim
      @TiagoTaquelim  Před 2 měsíci

      @@AK-vx4dy Totally agree with you!

  • @ruirodrigues3725
    @ruirodrigues3725 Před 3 měsíci +1

    Muito bom. Obrigado.

  • @rallokkcaz
    @rallokkcaz Před 3 měsíci +3

    What about having locks on each value in the map, and also having a read lock on the whole map when you iterate the keys? Seems simpler and there's less lock contention when accessing values within a certain range. I'm also a bit confused on how you're using the sha1 to create an index into the shards, that doesn't seem like it would give a fair distribution between shards. Would that be a case for consistent hashing instead? Also you're only taking the first byte from the sha1 which means your shards have a limit of 256 which I think should be mentioned here and also plays into how the distribution would be wonky.

    • @TiagoTaquelim
      @TiagoTaquelim  Před 3 měsíci +1

      Hey! Thanks for suggestions! I think a lock for each value could introduce additional complexity and overhead. Specially if the map has a lot of values. I think the current implementation provides a good balance between concurrency and simplicity.
      For the key hashing, I agree.

    • @AK-vx4dy
      @AK-vx4dy Před 2 měsíci +1

      More than 256 shards? Really? 😅

    • @rallokkcaz
      @rallokkcaz Před 2 měsíci

      Very true hahahaah, I'm just honestly just asking dumb questions because I love to see how people answer them.

  • @connormc711
    @connormc711 Před 2 měsíci

    Communicate to share memory; don’t share memory to communicate.

  • @indrranil24
    @indrranil24 Před 3 měsíci +1

    👍

  • @samuelbaruch8790
    @samuelbaruch8790 Před 2 měsíci

    What's your colosheme?

  • @sealoftime
    @sealoftime Před 3 měsíci +1

    Why not use sync.Map for that?

    • @TiagoTaquelim
      @TiagoTaquelim  Před 3 měsíci +1

      Hey! Thanks for sharing I didn't knew that existed.
      That is basically an implementation of what I've done here.

    • @sealoftime
      @sealoftime Před 3 měsíci +1

      @@TiagoTaquelimnot exactly, sync.Map works in a completely different way, very bizarre and complicated. Your solution is interesting nonetheless, thanks for sharing it ;)

    • @TiagoTaquelim
      @TiagoTaquelim  Před 3 měsíci

      @@sealoftime Oh I see! Thanks a bunch for sharing I'll be reading on it!