<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Data Structures on Brave New Geek</title><link>https://bravenewgeek.com/category/data-structures/</link><description>Recent content in Data Structures on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 03 Nov 2017 17:57:36 -0600</lastBuildDate><atom:link href="https://bravenewgeek.com/category/data-structures/index.xml" rel="self" type="application/rss+xml"/><item><title>Fast Topic Matching</title><link>https://bravenewgeek.com/fast-topic-matching/</link><pubDate>Wed, 28 Dec 2016 17:52:30 -0600</pubDate><guid>https://bravenewgeek.com/fast-topic-matching/</guid><description>&lt;p&gt;A common problem in messaging middleware is that of efficiently matching message topics with interested subscribers. For example, assume we have a set of subscribers, numbered 1 to 3:&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Subscriber&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Match Request&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;1&lt;/p&gt;
&lt;p&gt;forex.usd&lt;/p&gt;
&lt;p&gt;2&lt;/p&gt;
&lt;p&gt;forex.*&lt;/p&gt;
&lt;p&gt;3&lt;/p&gt;
&lt;p&gt;stock.nasdaq.msft&lt;/p&gt;
&lt;p&gt;And we have a stream of messages, numbered 1 to N:&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Message&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Topic&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;1&lt;/p&gt;
&lt;p&gt;forex.gbp&lt;/p&gt;
&lt;p&gt;2&lt;/p&gt;
&lt;p&gt;stock.nyse.ibm&lt;/p&gt;
&lt;p&gt;3&lt;/p&gt;
&lt;p&gt;stock.nyse.ge&lt;/p&gt;
&lt;p&gt;4&lt;/p&gt;
&lt;p&gt;forex.eur&lt;/p&gt;
&lt;p&gt;5&lt;/p&gt;
&lt;p&gt;forex.usd&lt;/p&gt;
&lt;p&gt;…&lt;/p&gt;
&lt;p&gt;…&lt;/p&gt;
&lt;p&gt;N&lt;/p&gt;
&lt;p&gt;stock.nasdaq.msft&lt;/p&gt;
&lt;p&gt;We are then tasked with routing messages whose topics match the respective subscriber requests, where a “&lt;em&gt;*”&lt;/em&gt; wildcard matches any word. This is frequently a bottleneck for message-oriented middleware like ZeroMQ, RabbitMQ, ActiveMQ, TIBCO EMS, et al. Because of this, there are a number of &lt;a href="http://zeromq.org/whitepapers:message-matching"&gt;well-known&lt;/a&gt; &lt;a href="http://wso2.com/library/articles/2015/05/article-fast-topic-matching-algorithm-implementation-for-wso2-message-broker/"&gt;solutions&lt;/a&gt; &lt;a href="https://www.rabbitmq.com/blog/2010/09/14/very-fast-and-scalable-topic-routing-part-1/"&gt;to the problem&lt;/a&gt;. In this post, I’ll describe some of these solutions, as well as a novel one, and attempt to quantify them through benchmarking. As usual, the code is available &lt;a href="https://github.com/tylertreat/fast-topic-matching"&gt;on GitHub&lt;/a&gt;.&lt;/p&gt;</description></item><item><title>So You Wanna Go Fast?</title><link>https://bravenewgeek.com/so-you-wanna-go-fast/</link><pubDate>Wed, 24 Feb 2016 19:30:14 -0600</pubDate><guid>https://bravenewgeek.com/so-you-wanna-go-fast/</guid><description>&lt;p&gt;I originally proposed this as a &lt;a href="https://www.gophercon.com/"&gt;GopherCon&lt;/a&gt; talk on writing “high-performance Go”, which is why it may seem rambling, incoherent, and—at times—not at all related to Go. The talk was rejected (probably because of the rambling and incoherence), but I still think it’s a subject worth exploring. The good news is, since it was rejected, I can take this where I want. The remainder of this piece is mostly the outline of that talk with some parts filled in, some meandering stories which may or may not pertain to the topic, and some lessons learned along the way. I think it might make a good talk one day, but this will have to do for now.&lt;/p&gt;</description></item><item><title>Breaking and Entering: Lose the Lock While Embracing Concurrency</title><link>https://bravenewgeek.com/breaking-and-entering-lose-the-lock-while-embracing-concurrency/</link><pubDate>Sun, 27 Dec 2015 19:12:53 -0600</pubDate><guid>https://bravenewgeek.com/breaking-and-entering-lose-the-lock-while-embracing-concurrency/</guid><description>&lt;p&gt;&lt;em&gt;This article originally appeared on Workiva’s engineering blog as a &lt;a href="https://techblog.workiva.com/tech-blog/breaking-and-entering-lose-lock-while-embracing-concurrency-part-i"&gt;two-part series&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;Providing robust message routing was a priority for us at Workiva when building our distributed messaging infrastructure. This encompassed directed messaging, which allows us to route messages to specific endpoints based on service or client identifiers, but also topic fan-out with support for wildcards and pattern matching.&lt;/p&gt;
&lt;p&gt;Existing message-oriented middleware, such as RabbitMQ, provide varying levels of support for these but don’t offer the rich features needed to power Wdesk. This includes transport fallback with graceful degradation, tunable qualities of service, support for client-side messaging, and pluggable authentication middleware. As such, we set out to build a new system, not by reinventing the wheel, but by repurposing it.&lt;/p&gt;</description></item><item><title>Probabilistic algorithms for fun and pseudorandom profit</title><link>https://bravenewgeek.com/probabilistic-algorithms-for-fun-and-pseudorandom-profit/</link><pubDate>Sun, 06 Dec 2015 13:00:19 -0600</pubDate><guid>https://bravenewgeek.com/probabilistic-algorithms-for-fun-and-pseudorandom-profit/</guid><description>&lt;iframe loading="lazy" style="border: 1px solid #CCC; border-width: 1px; margin-bottom: 5px; max-width: 100%;" src="//www.slideshare.net/slideshow/embed_code/key/u8dzHRRAHnnItb" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" allowfullscreen="allowfullscreen"&gt;&lt;/iframe&gt;
&lt;p&gt;&lt;strong&gt;&lt;a href="//www.slideshare.net/TylerTreat/probabilistic-algorithms-for-fun-and-pseudorandom-profit" title="Probabilistic algorithms for fun and pseudorandom profit"&gt;Probabilistic algorithms for fun and pseudorandom profit&lt;/a&gt;&lt;/strong&gt; from &lt;strong&gt;&lt;a href="//www.slideshare.net/TylerTreat"&gt;Tyler Treat&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;</description></item><item><title>Stream Processing and Probabilistic Methods: Data at Scale</title><link>https://bravenewgeek.com/stream-processing-and-probabilistic-methods/</link><pubDate>Fri, 13 Feb 2015 10:49:07 -0600</pubDate><guid>https://bravenewgeek.com/stream-processing-and-probabilistic-methods/</guid><description>&lt;p&gt;Stream processing and related abstractions have become all the rage following the rise of systems like Apache Kafka, Samza, and the &lt;a href="http://en.wikipedia.org/wiki/Lambda_architecture"&gt;Lambda architecture&lt;/a&gt;. Applying the idea of immutable, append-only &lt;a href="http://blog.confluent.io/2015/01/29/making-sense-of-stream-processing/"&gt;event sourcing&lt;/a&gt; means we’re storing more data than ever before. However, as the cost of storage continues to decline, it’s becoming more feasible to store more data for longer periods of time. With immutability, how the data &lt;em&gt;lives&lt;/em&gt; isn’t interesting anymore. It’s all about how it &lt;em&gt;moves&lt;/em&gt;.&lt;/p&gt;</description></item></channel></rss>