Happy birthday Redis!
Today Redis is 5 years old, at least if we count starting from the initial HN announcement [1], that’s actually a good starting point. After all an open source project really exists as soon as it is public. I’m a bit shocked I worked for
Today Redis is 5 years old, at least if we count starting from the initial HN announcement [1], that’s actually a good starting point. After all an open source project really exists as soon as it is public.I’m a bit shocked I worked for five years straight to the same thing. The opportunities for learning new things I had because of the directions where Redis pushed me, and the opportunities to learn new things that I missed because I had almost consistently no time for random hacking, are huge.
My feeling today is that the Redis project was possible because of the great coders I encountered in my journey: they made Redis popular adopting it in its infancy, since great coders don’t follow the hype. Great coders provided outstanding additions to Redis in the form of patches and ideas that were able to surpass my instinct to be conservative when the topic was to extend the system or accept external contributions. More great coders made possible to sponsor Redis when it was in its infancy, recognizing that there was something interesting about it, and more great coders applied it in the right way to solve problems in the course of many years, wrote an incredible ecosystem of client libraries and tools, and helped other coders to apply it when it was not clear what was the best way to solve a given problem.
The Redis community is outstanding because in some way it managed to attract a number of great coders.
I learned that in the future, whatever I’ll do more coding or I’ll be in a team to build something great in a different role, my top priority will be to stay with great coders, and I learned that they are not easy to recognize at first: their abilities don’t correlate with the number of followers on Twitter nor with the number of Github repositories. You have to discover great coders one after the other, and the biggest gift that Redis provided to me, was to get exposed to many of them.
In the course of five years there was also time, for me, to evolve my idea of what Redis is. The idea I’ve of Redis today is that its contribution should be to try to explore corner designs and bizzarre ideas. After all there are large teams of people much smarter than me trying to work on the hard problems applying the best technologies available.
Redis will continue to be a small research in more obscure places of the design space. After all I’ve the feeling that it helped to popularize certain non obvious ideas, like using data structures as data model for key value stores and caches, or that it is possible to apply scripting to database systems in a different way than stored procedures.
However for Redis to be able to do this research, I should be ready to be opinionated and change development direction when something is weak. This was done in the past, deprecating swap and diskstore, but should be done even more in the future.
Moreover Redis should be able to purse different goals at the same time: once Redis 3.0 will be stable, the design of Redis Cluster is conceived in order to leave my hands free about changes in the data model, without too much limits or compromises. This will result in a Redis 3.2 release that will focus again on the API, stressing one of the initial and fundamental aspects of Redis: caching, data model and computation.
It is entirely not obvious to me, after five years, to consider the Redis journey still ongoing, and I’m happy about it, because my motivations are not investors or shares, nor that I’m particularly in love with Redis as a project. If something new appears tomorrow that marginalizes Redis and makes it totally useless I’ll be very happy to start some new gig, after all this is how technology works: for cycles. And, after all, starting from scratch with something new is always exciting. However currently I believe there is more to do about Redis, and I’ll be happy to continue my work on it in the next weeks.
[1] https://news.ycombinator.com/item?id=494649 Comments

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제









PHP 개발에서 PHP의 CURL 라이브러리를 사용하여 JSON 데이터를 보내면 종종 외부 API와 상호 작용해야합니다. 일반적인 방법 중 하나는 컬 라이브러리를 사용하여 게시물을 보내는 것입니다 ...

Docker 환경을 사용할 때 Docker 환경에 Extensions를 설치하기 위해 PECL을 사용하여 오류의 원인 및 솔루션. 종종 일부 두통이 발생합니다 ...

Linux 터미널에서 Python 사용 ...

DebianHadoop 클러스터의 성능을 향상 시키려면 하드웨어, 소프트웨어, 리소스 관리 및 성능 튜닝에서 시작해야합니다. 다음은 몇 가지 주요 최적화 전략 및 제안입니다. 1. 하드웨어 및 시스템 구성 선택 하드웨어 구성을 선택하십시오. 하드웨어 구성을 선택하십시오. 실제 애플리케이션 시나리오에 따라 적절한 CPU, 메모리 및 스토리지 장치를 선택하십시오. SSD 가속 I/O : I/O 작동 속도를 향상시키기 위해 가능한 한 SSD (Solid State Hard Drive)를 사용하십시오. 메모리 확장 : 더 큰 데이터 처리 및 작업에 대처하기 위해 Namenode 및 Datanode 노드에 충분한 메모리를 할당합니다. 2. 소프트웨어 구성 최적화 Hadoop 구성 파일 조정 : Core-Site.xml : HDFS 기본 파일 시스템 구성

이 기사는 데비안 시스템에서 PostgresQL 데이터베이스를 모니터링하는 다양한 방법과 도구를 소개하여 데이터베이스 성능 모니터링을 완전히 파악할 수 있도록 도와줍니다. 1. PostgreSQL을 사용하여 빌드 인 모니터링보기 PostgreSQL 자체는 데이터베이스 활동 모니터링 활동을위한 여러보기를 제공합니다. PG_STAT_REPLICATION : 특히 스트림 복제 클러스터에 적합한 복제 상태를 모니터링합니다. PG_STAT_DATABASE : 데이터베이스 크기, 트랜잭션 커밋/롤백 시간 및 기타 주요 지표와 같은 데이터베이스 통계를 제공합니다. 2. 로그 분석 도구 PGBADG를 사용하십시오

Dockerfile에서 CMD 명령의 효율적인 사용에 대해 많은 새로운 Docker 사용자가 CMD를 사용하고 있습니다 ...

Java의 Jammed Calling Python Code의 분석 및 솔루션. Java로 Python Code를 호출 할 때 종종 프로그램과 같은 어려운 문제가 발생합니다 ...
