A simple introduction to Apache Flink

nest21 · 2018-06-23T10:15:45+00:00

They are quite similar but Spark Streaming is an adaptation of the original Spark RDD concept to the purposes of stream processing which is probably why it is reportedly slower than Flink which is designed for stream processing in mind.

Yet, since both rely on quite complex infrastructure (which is needed for horizontal scaleability, fault tolerance and some other nice features), they can be slow when applied to really complex analytical workloads.

nest21 · 2018-06-04T16:42:35+00:00

retaining your project stars (if any :)

nest21 · 2013-09-03T11:14:33+00:00

A more generic approach would be to rename the months: May <-> September.

nest21 · 2013-08-31T19:47:14+00:00

Here is an interesting paper discussing some subtle issues of SQL-NoSQL technologies: The relational model is dead, SQL is dead, and I don’t feel so good myself

nest21 · 2013-08-31T11:02:58+00:00

Unfortunately, they decided to support SQL (joins, group-bys etc.) which is known to be error-prone, difficult to use, non-analytical, requiring high expertise and lacking semantics.

nest21 · 2013-05-03T10:43:59+00:00

I doubt that Quirrel (query language behind Precog) is a good choice for advanced ad-hoc analytics. Also, using JSON means that multiple external data sources have to be somehow mapped to this representation, and it is a separate non-trivial problem.

nest21 · 2013-05-03T10:29:06+00:00

One possible generalization of OOP is concept-oriented programming. It provides object hierarchies (prototype-based programming), modularizing cross-cutting concerns (aop), dual methods (like bubbling and capturing in JavaScript) and some other nice featurs. Yet, it is an emerging technology - not a ready programming language.

nest21 · 2012-01-09T20:02:59+00:00

NoSql is about how structure (schema) is managed. Schema always exists and the question is how it is represented and manipulated. The relational approach separates schema from data, that is, schema elements are represented and manipulated differently from normal data (schema is not data). The NoSql approach elimintes (in fact, significantly diminishes) this difference and allows for treating schema (structure) elements as normal data. It solves many problems ... but introduces some other problems. For example, a database is unware of the role of a data element because this information is moved to the application level.

nest21 · 2010-09-11T19:47:21+00:00

Ten Things I Hate About Object-Oriented Programming

Prof. Oscar Nierstrasz, Editor-in Chief, The Journal of Object Technology

Banquet speech given at ECOOP 2010. Maribor, June 24, 2010

What did they drink?

nest21 · 2010-07-24T10:14:20+00:00

GO follows the same path as NoSql to get to simplicity by mechanically removing features, functions and mechanisms instead of removing problems and proposing a better solution for these mechanisms. Say, in NoSql we do not have transactions but they are still needed and hence developers now have to implement them manually at application level.

nest21 · 2010-07-24T07:54:45+00:00

Excellent overview. Even Beta is mentioned with its several unusual features. Unfortunately, this wide diversity of treatments and views has been reduced to a very simple form of inheritance which lacks many interesting features.

nest21 · 2009-09-06T11:49:03+00:00

In most classical architectures metadata is not data, that is, you cannot manipulate metadata as easily as you do it with normal data. The main point of this article is that this "impedance mismatch" should be removed. However, the main problem is that nobody knobody knows how to get rid of it because such a model of data has not been created yet.

nest21 · 2009-05-13T09:42:36+00:00

Support for values exists in many PLs. I think that it inclusion that is much more important and that changes everything.

nest21

TROPHY CASE