Los datos son el centro de la arquitectura.
Como arquitecto en la industria de Internet, casi todos los días tratamos con varios tipos de datos, tantos años de experiencia, diferentes industrias y diferentes sistemas, desde el nivel técnico, abstracto hasta el más alto, resumido en una oración:
Los datos son el centro de la arquitectura.
Si lo piensas bien, todo el trabajo que realizamos gira en torno a los datos. La generación de datos, el almacenamiento de datos, el consumo de datos, el flujo de datos ... solo cambian la forma y el servicio de datos de acuerdo con las diferentes necesidades. Los estudiantes en el departamento de computación aún pueden recordar la oración que el maestro dijo: programa = algoritmo + estructura de datos. Imité audazmente esta oración: sistema = lógica de negocios x datos . Se puede decir que muchos problemas arquitectónicos son causados por la capa de datos, como los problemas causados por el "sistema de chimenea" común, especialmente el problema de la isla de datos. De hecho, la razón esencial es que la capa de datos no se borra. Si piensa en la estructura, puede ser "dolores de cabeza, cabeza, pies, pies", y será incómodo pasar mucho tiempo. Por el contrario, si la capa de datos se maneja bien, será como abrir los "Dos Gobernadores", que tiene el efecto de cuatro o dos libras. .
Pero el ideal suele estar lleno, pero la realidad es muy delgada. Al menos cuando salimos para iniciar un negocio hace cinco años, sentimos que ningún sistema podía resolver muy bien el problema de los datos. Probablemente los lectores curiosos preguntarán: ¿Hay Hadoop? ¿Y NoSQL? ¿No importa qué tan mala se pueda dividir la base de datos relacional en bibliotecas y tablas? De hecho, estos son casi todos los candidatos para lidiar con problemas de almacenamiento ese año. La característica común de estas soluciones es: no es perfecta.
Específicamente, estas soluciones no son muy grandes para escenarios de aplicaciones de datos. Para servicios más complejos, es posible que necesite usar varias soluciones al mismo tiempo para completar la cobertura . Esta es la razón por la cual los servicios de Internet se han vuelto cada vez más complejos en los últimos años, las canalizaciones de datos como Kafka se han vuelto cada vez más populares. Para una cobertura total, es necesario construir caminos entre "islas".
Nos preguntamos si podríamos tener un sistema que cubriera tantas escenas como sea posible con una interfaz unificada.
Necesitamos una fuente única de verdad. Los datos deben ejecutarse en todos los rincones de la lógica de la aplicación. En mi sistema ideal, el acceso a cualquier información no debe estar restringido (no considere los permisos y la seguridad primero, este es otro problema). "Límite" es más amplio, por ejemplo: no hay límite superior de capacidad, siempre que haya suficientes recursos físicos, el sistema se puede expandir infinitamente; no hay límite de modelo de acceso, podemos asociar y agregar datos libremente; no hay límite de consistencia; No se requiere intervención humana ...
Arquitectura con base de datos distribuida como centro unificado
Estaba particularmente fascinado por un drama estadounidense: Persona de interés (seguimiento sospechoso). En esta serie de televisión, hay una inteligencia artificial divina, The Machine, que recopila todos los datos y los analiza para predecir o intervenir en las acciones de las personas futuras. Aunque este drama estadounidense sigue siendo un tema más ortodoxo de los héroes, pero lo que más me fascina es, ¿podemos diseñar una máquina? Aunque no he sido un experto en IA hasta ahora, parece factible diseñar una base de datos para The Machine. En el curso de comenzar un negocio en los últimos años, hemos descubierto que los puntos más interesantes son:
Es posible utilizar una base de datos distribuida como una arquitectura central unificada.
¿Cómo entender esto? Por ejemplo, al igual que los problemas provocados por la división mencionada anteriormente, la fragmentación de la capa de datos necesariamente significa que la capa de negocios debe ser más complicada de inventar. De hecho, muchos ingenieros prefieren usar el pensamiento lineal para pensar en mantener el sistema. Costo Pero la experiencia real nos dice que este no es el caso. La complejidad de un sistema con una sola base de datos y diez bases de datos en realidad no es simple 10x. Considerando el flujo de datos, el costo de mantenimiento solo puede ser mayor. No hay otros problemas provocados por la heterogeneidad.
¿Cómo se ve una arquitectura distribuida centrada en la base de datos? Es fácil entender que el centro de toda la arquitectura es un sistema de almacenamiento con suficiente cobertura de escena y escalabilidad horizontal ilimitada. La mayor parte del flujo de datos está restringido a esta base de datos, de modo que la capa de aplicación puede estar casi sin estado, ya que esta base de datos central es responsable de la mayor parte del estado, cada aplicación puede ser acelerada por su propia caché. Lo que quiero recordar aquí es por qué enfatizo la capacidad de expansión horizontal anterior porque la capacidad de expansión limitada también es una razón importante para la división. Nunca hemos tenido una manera de predecir el futuro con precisión. Es difícil para nosotros imaginar cambios en nuestro negocio incluso después de un año (piense en la epidemia). Hay un viejo dicho que es bueno: la única constante es el cambio.
Otra pregunta frecuente, ¿por qué debería enfatizar que la capa de caché debe estar más cerca de la capa de negocios, o por qué la base de datos gigante en el centro no debería asumir la responsabilidad del almacenamiento en caché? Tengo entendido que solo la empresa comprende mejor a la empresa, sabe qué estrategia se debe usar para almacenar en caché los datos y, por consideraciones de rendimiento (baja latencia), tiene sentido que la caché esté más cerca de la empresa.
En correspondencia con la oración anterior, "la única constante es el cambio", el mayor beneficio de esta estructura es "cambiar con constante", o una palabra más simple: conciso. Google realmente pensó en este problema muy temprano, porque comprendieron lo que es realmente complicado desde el principio.
Otro ejemplo es HTAP. Si presta atención al desarrollo de la base de datos, debe estar familiarizado con el término HTAP recientemente. De hecho, la esencia de HTAP en mi opinión es la cobertura mencionada anteriormente. La siguiente es una arquitectura típica:
La arquitectura de datos tradicional generalmente separa OLTP, OLAP y los almacenes de datos fuera de línea, cada sistema realiza sus propias tareas y se sincroniza a través de una canalización independiente (a veces con ETL). Así es como se ve un sistema HTAP:
Aunque en la superficie, es solo una simple integración de la capa de interfaz, pero este significado es de gran alcance. Primero, los detalles de la sincronización de datos están ocultos, lo que significa que la capa de la base de datos puede decidir cómo sincronizar los datos por sí misma. Además, Debido a que el motor OLTP y el motor OLAP están en el mismo sistema, muchos detalles no se perderán durante el proceso de sincronización, como: información de la transacción, lo que significa que el motor de análisis interno puede hacer cosas que OLAP tradicional no puede hacer. . Además, para el uso de la capa empresarial, un sistema menos significa una experiencia más unificada y menores costos de aprendizaje y transformación. No subestime el poder de la unificación.
Donde esta el futuro
Lo anterior es lo que sucedió en los últimos cinco años, y casi se ha convertido en una realidad paso a paso según las ideas que teníamos cuando comenzamos un negocio. Entonces, ¿qué sucederá en los próximos cinco años? A medida que se profundiza la comprensión de la industria y la tecnología, al menos una cosa de la que estoy convencido es:
La programación flexible será la capacidad central de la base de datos en el futuro
Nadie negará que el cambio más grande en la tecnología de TI en la última década fue provocado por la nube, y esta revolución aún está en progreso. ¿Cuáles son las capacidades principales de la nube? Creo que es elástico. La granularidad de la asignación de recursos informáticos se ha vuelto cada vez más fina, como cambiar de solo comprar una casa a alquilar una casa, e incluso tan flexible como quedarse en un hotel. ¿Qué significa esto? La esencia es que no tenemos que pagar por adelantado por los picos comerciales "imaginarios".
En el pasado, tanto si compramos servidores como si alquilamos gabinetes, necesitábamos establecer un monto por adelantado. Cuando el negocio pico no llegó, de hecho, estos costos ya se pagaron por adelantado. La aparición de la nube ha convertido la elasticidad en una capacidad fundamental de la infraestructura, y espero que ocurra lo mismo con las bases de datos. El Hospital de Ginecología de Zhengzhou es bueno: http://www.xbhnzzyy.com/
Muchos amigos pueden tener dudas. ¿No es cierto que casi todas las bases de datos afirman que admiten una expansión horizontal transparente? De hecho, espero que todos no entiendan por poco "programación flexible" como escalabilidad, y la palabra se centra en "programación". Permítanme darles algunos ejemplos para facilitar su comprensión:
¿Puede la base de datos identificar automáticamente la carga de trabajo y escalar automáticamente de acuerdo con la carga de trabajo? Por ejemplo: anticipe que se acerca el pico, compre máquinas automáticamente, cree más copias de los datos activos y redistribuya los datos y amplíe la capacidad por adelantado. Después del pico comercial, la máquina de reciclaje automática se utiliza para reducir el volumen.
数据库能不能感知业务特点，根据访问特点决定分布？例如：如果数据带有明显的地理特征（比如，中国的用户大概率在中国访问，美国用户在美国），系统将自动的将数据的地理特征在不同的数据中心放置。
数据库能不能感知查询的类型和访问频度，从而自动决定不同类型数据的存储介质？例如：冷数据自动转移到 S3 之类比较便宜的存储，热数据放在高配的闪存上，而且冷热数据的交换完全是对业务方透明的。
这里提到的一切背后都依赖的是「弹性调度」能力。未来我相信物理资源的成本会持续的降低，计算资源的单价持续下降带来的结果是：当存储成本和计算资源变得不是问题的时候，问题就变成「如何高效的分配资源」。如果将高效分配作为目标的话，「能调度」就是显而易见的基础。 当然就像一切事物发展的客观规律一样，学会跑步之前，先要学会走路，我相信在接下来的一段时间内，我们会看到第一批初步拥有这样能力的新型数据库，让我们拭目以待。
下一个阶段是智能
对于更远的未来是怎么样子的？我不知道，但是就像 The Machine 一样，只有足够数据才能诞生出智能，我相信就像我们不了解宇宙和海洋一样，我们现在对于数据的认识一定是肤浅的，甚至大量的数据我们都还没记录下来，一定有更大奥秘隐藏在这海量的数据中，从数据中能获取什么样的洞察，能够怎么样更好的改变我们的生活，我并不知道，但是做这件事情的主角我猜不会是人类。虽然在这个小节我们讨论的东西可能就有点像科幻小说了，不过我愿意相信这样的未来，从数据的海洋中诞生出新的智能体。郑州试管婴儿费用：http://jbk.39.net/yiyuanfengcai/tsyl_zztjyy/3100/
尾声
创业这五年的时间，回头看看那个最朴素的出发点：写一个更好的数据库彻底解决烦人的 MySQL 分库分表问题。似乎也算没有偏离初心，但是在这个旅途中一步步看到了更大的世界，也越来越有能力和信心将我们相信的东西变为现实：
我有一个梦想，未来的软件工程师不用再为维护数据库加班熬夜，各种数据相关的问题都将被数据库自动且妥善的处理；
我有一个梦想，未来我们对数据的处理将不再碎片化，任何业务系统都能够方便的存储和获取数据；
我有一个梦想，未来的我们在面临数据的洪流时候，能从容地以不变应万变。
最近我听到一句话，我个人很喜欢：雄心的一半是耐心。构建一个完美的数据库并不是一朝一夕的工作，但是我相信我们正走在正确的道路上。
凡所过往，皆为序章。