<?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>algorithms on Brave New Geek</title><link>https://bravenewgeek.com/tag/algorithms-2/</link><description>Recent content in algorithms on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 13 Sep 2018 23:23:09 +0600</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/algorithms-2/index.xml" rel="self" type="application/rss+xml"/><item><title>Building a Distributed Log from Scratch, Part 2: Data Replication</title><link>https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-2-data-replication/</link><pubDate>Wed, 27 Dec 2017 12:26:55 -0600</pubDate><guid>https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-2-data-replication/</guid><description>&lt;p&gt;In &lt;a href="https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-1-storage-mechanics/"&gt;part one&lt;/a&gt; of this series we introduced the idea of a message log, touched on why it’s useful, and discussed the storage mechanics behind it. In part two, we discuss data replication.&lt;/p&gt;
&lt;p&gt;We have our log. We know how to write data to it and read it back as well as how data is persisted. The caveat to this is, although we have a durable log, it’s a single point of failure (SPOF). If the machine where the log data is stored dies, we’re SOL. Recall that one of our three priorities with this system is high availability, so the question is how do we achieve high availability and fault tolerance?&lt;/p&gt;</description></item><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>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><item><title>Not Invented Here</title><link>https://bravenewgeek.com/not-invented-here/</link><pubDate>Sat, 06 Dec 2014 14:17:52 -0600</pubDate><guid>https://bravenewgeek.com/not-invented-here/</guid><description>&lt;p&gt;Engineers love engineering things. The reason is self-evident (and maybe self-fulfilling—why else would you be an engineer?). We like to think we’re pretty good at solving problems. Unfortunately, this mindset can, on occasion, yield undesirable consequences which might not be immediately apparent but all the while damaging.&lt;/p&gt;
&lt;p&gt;Developers are all in tune with the idea of “don’t reinvent the wheel,” but it seems to be eschewed sometimes, deliberately or otherwise. People don’t generally write their own merge sort, so why would they write their own consensus protocol? Anecdotally speaking, &lt;a href="https://groups.google.com/d/msg/redis-db/Oazt2k7Lzz4/MPhvXVizCAYJ"&gt;they do&lt;/a&gt;.&lt;/p&gt;</description></item><item><title>Probabilistic Primality Testing</title><link>https://bravenewgeek.com/probabilistic-primality-testing/</link><pubDate>Sun, 02 Dec 2012 08:30:40 +0600</pubDate><guid>https://bravenewgeek.com/probabilistic-primality-testing/</guid><description>&lt;p&gt;An exceedingly common question asked in coding interviews is to write a function, method, algorithm, whatever to determine if a number is prime. Prime numbers have a wide range of applications in computer science, particularly with regard to cryptography. The idea is that factoring large numbers into their prime factors is extremely difficult.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;“Because both the system’s privacy and the security of digital money depend on encryption, a breakthrough in mathematics or computer science that defeats the cryptographic system could be a disaster. The obvious mathematical breakthrough would be the development of an easy way to factor large prime numbers.” -Bill Gates, &lt;a href="http://www.amazon.com/Road-Ahead-Book-CD-Pack/dp/1405879327"&gt;The Road Ahead&lt;/a&gt;&lt;/p&gt;</description></item></channel></rss>